Re: [PATCH v3 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

On Fri, 4 Mar 2016, Franklin S Cooper Jr. wrote: > So what you want to happen > is already happening in the driver. So I don't believe > simple-bus is needed. OK great, even better! - Paul

Re: [PATCH v4 5/7] mm, kasan: Stackdepot implementation. Enable stackdepot for SLAB

2016-03-04 18:06 GMT+03:00 Alexander Potapenko : > On Fri, Mar 4, 2016 at 4:01 PM, Andrey Ryabinin > wrote: >> 2016-03-04 17:52 GMT+03:00 Alexander Potapenko : >>> On Tue, Mar 1, 2016 at 12:57 PM, Andrey Ryabinin >>> wrote: >>> + >>> + stack->hash = hash; >>> + stack->size

[PATCH v3 09/19] x86, boot: Split kernel_ident_mapping_init to another file

From: Yinghai Lu We need to include that in boot::decompress_kernel stage to set new ident mapping. Also add checking for __pa/__va macro definition, as we need to override them in boot::decompress_kernel stage. Reviewed-by: Kees Cook Signed-off-by:

[PATCH v3 09/19] x86, boot: Split kernel_ident_mapping_init to another file

From: Yinghai Lu We need to include that in boot::decompress_kernel stage to set new ident mapping. Also add checking for __pa/__va macro definition, as we need to override them in boot::decompress_kernel stage. Reviewed-by: Kees Cook Signed-off-by: Yinghai Lu ---

Re: [PATCH] Fix NULL ptr dereference in pci_bus_assign_domain_nr() on ARM

On Fri, Mar 04, 2016 at 07:13:49AM +0100, Krzysztof Hałasa wrote: > Hi Bjorn, > > Bjorn Helgaas writes: > > > On Tue, Mar 01, 2016 at 07:07:18AM +0100, Krzysztof Hałasa wrote: > >> Many ARM platforms use a wrapper: > >> /* > >> * Compatibility wrapper for older platforms

[PATCH v3 14/19] x86, kaslr: Add two functions which will be used later

Function store_slot_info() is used to calculate the slot info of passed in memory region and store it into slot_areas[]. Function mem_min_overlap is used to iterate all avoid regions to find the one which overlap with it in the lowest address. E.g there's a memory region[1024M, 2048M), after

[PATCH v3 13/19] x86, kaslr: Introduce struct slot_area to manage randomization slot info

Kernel is expected to be randomly reloaded anywhere in the whole physical memory area, it could be near 64T at most. In this case there could be about 4*1024*1024 randomization slots if CONFIG_PHYSICAL_ALIGN is 0x100. Currently the starting address of candidate position is stored into array

[PATCH v3 18/19] x86, kaslr: Remove useless codes

Several auxiliary functions and slots[] are not needed any more since struct slot_area is used to store the slot info of kaslr now. Hence remove them in this patch. Signed-off-by: Baoquan He --- arch/x86/boot/compressed/aslr.c | 24 1 file changed, 24

[PATCH v3 19/19] x86, kaslr: Allow random address to be below loaded address

From: Yinghai Lu Now new randomized output can only be chosen from regions above loaded address. In this case, for bootloaders like kexec which always loads kernel near the end of ram, it doesn't do randomization at all. Or kernel is loaded in a very big starting address, we

Re: [PATCH] Fix NULL ptr dereference in pci_bus_assign_domain_nr() on ARM

On Fri, Mar 04, 2016 at 07:13:49AM +0100, Krzysztof Hałasa wrote: > Hi Bjorn, > > Bjorn Helgaas writes: > > > On Tue, Mar 01, 2016 at 07:07:18AM +0100, Krzysztof Hałasa wrote: > >> Many ARM platforms use a wrapper: > >> /* > >> * Compatibility wrapper for older platforms that do not care about

[PATCH v3 14/19] x86, kaslr: Add two functions which will be used later

Function store_slot_info() is used to calculate the slot info of passed in memory region and store it into slot_areas[]. Function mem_min_overlap is used to iterate all avoid regions to find the one which overlap with it in the lowest address. E.g there's a memory region[1024M, 2048M), after

[PATCH v3 13/19] x86, kaslr: Introduce struct slot_area to manage randomization slot info

Kernel is expected to be randomly reloaded anywhere in the whole physical memory area, it could be near 64T at most. In this case there could be about 4*1024*1024 randomization slots if CONFIG_PHYSICAL_ALIGN is 0x100. Currently the starting address of candidate position is stored into array

[PATCH v3 18/19] x86, kaslr: Remove useless codes

Several auxiliary functions and slots[] are not needed any more since struct slot_area is used to store the slot info of kaslr now. Hence remove them in this patch. Signed-off-by: Baoquan He --- arch/x86/boot/compressed/aslr.c | 24 1 file changed, 24 deletions(-) diff

[PATCH v3 19/19] x86, kaslr: Allow random address to be below loaded address

From: Yinghai Lu Now new randomized output can only be chosen from regions above loaded address. In this case, for bootloaders like kexec which always loads kernel near the end of ram, it doesn't do randomization at all. Or kernel is loaded in a very big starting address, we should not give up

[PATCH v3 17/19] x86, kaslr: Add support of kernel physical address randomization above 4G

In kaslr implementation mechanism, process_e820_entry and slots_fetch_random are 2 key functions. process_e820_entry is used to parse passed in memory region and store available slot area information into array slot_areas[]. slots_fetch_random is used to get a random value and translate it into

[PATCH v3 15/19] x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address

Kaslr extended kernel text mapping region size from 512M to 1G, namely CONFIG_RANDOMIZE_BASE_MAX_OFFSET. This means kernel text can be mapped to below region: [__START_KERNEL_map + LOAD_PHYSICAL_ADDR, __START_KERNEL_map + 1G] Introduce a function find_random_virt_offset() to get random value

[PATCH] null_blk: add lightnvm null_blk device to the nullb_list

After register null_blk devices into lightnvm, we forget to add these devices to the the nullb_list, makes them invisible to the null_blk driver. Signed-off-by: Wenwei Tao --- drivers/block/null_blk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately

On x86_64, in old kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually

Re: [PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen

On Fri, 4 Mar 2016, Shannon Zhao wrote: > On 2016/3/4 20:24, Stefano Stabellini wrote: > > On Fri, 4 Mar 2016, Shannon Zhao wrote: > > > >From: Shannon Zhao > > > > > > > >ACPI 6.0 introduces a new table STAO to list the devices which are used > > > >by Xen and can't be

[PATCH v3 17/19] x86, kaslr: Add support of kernel physical address randomization above 4G

In kaslr implementation mechanism, process_e820_entry and slots_fetch_random are 2 key functions. process_e820_entry is used to parse passed in memory region and store available slot area information into array slot_areas[]. slots_fetch_random is used to get a random value and translate it into

[PATCH v3 15/19] x86, kaslr: Introduce fetch_random_virt_offset to randomize the kernel text mapping address

Kaslr extended kernel text mapping region size from 512M to 1G, namely CONFIG_RANDOMIZE_BASE_MAX_OFFSET. This means kernel text can be mapped to below region: [__START_KERNEL_map + LOAD_PHYSICAL_ADDR, __START_KERNEL_map + 1G] Introduce a function find_random_virt_offset() to get random value

[PATCH] null_blk: add lightnvm null_blk device to the nullb_list

After register null_blk devices into lightnvm, we forget to add these devices to the the nullb_list, makes them invisible to the null_blk driver. Signed-off-by: Wenwei Tao --- drivers/block/null_blk.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/null_blk.c

[PATCH v3 16/19] x86, kaslr: Randomize physical and virtual address of kernel separately

On x86_64, in old kaslr implementaion only physical address of kernel loading is randomized. Then calculate the delta of physical address where vmlinux was linked to load and where it is finally loaded. If delta is not equal to 0, namely there's a new physical address where kernel is actually

Re: [PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen

On Fri, 4 Mar 2016, Shannon Zhao wrote: > On 2016/3/4 20:24, Stefano Stabellini wrote: > > On Fri, 4 Mar 2016, Shannon Zhao wrote: > > > >From: Shannon Zhao > > > > > > > >ACPI 6.0 introduces a new table STAO to list the devices which are used > > > >by Xen and can't be used by Dom0. On Xen

[PATCH v3 12/19] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G

When process 32 bit relocation tables a local variable 'extended' is defined to calculate the physical address of relocs entry. However its type is 'int' which is enough for i386, but not enough for x86_64. That's why relocation can only be handled under 2G. Otherwise a overflow will happen and

[PATCH v3 12/19] x86, kaslr: Fix a bug that relocation can not be handled when kernel is loaded above 2G

When process 32 bit relocation tables a local variable 'extended' is defined to calculate the physical address of relocs entry. However its type is 'int' which is enough for i386, but not enough for x86_64. That's why relocation can only be handled under 2G. Otherwise a overflow will happen and

[PATCH v3 06/19] x86, kaslr: Clean up useless code related to run_size.

From: Yinghai Lu So now we use the below formula to get run_size. run_size = VO__end - VO__text Let's remove code for old run_size calculation and clean up the places where run_size need be passed in and out. Cc: "H. Peter Anvin" Cc: Josh Triplett

[PATCH v3 08/19] x86, kaslr: Consolidate mem_avoid array filling

From: Yinghai Lu We are going to support kaslr with 64bit above 4G, and new random output could be anywhere. Array mem_avoid is used for kaslr to search new output address. Current code only track range that is after output+output_size. So we need to track all ranges instead

[PATCH v3 07/19] x86, kaslr: Get correct max_addr for relocs pointer

From: Yinghai Lu There is boundary checking for pointer in kaslr relocation handling. Current code is using output_len, and that is VO (vmlinux after objcopy) file size plus vmlinux.relocs file size. That is not right, as we should use loaded address for running. At that

pull-request: wireless-drivers 2016-03-04

Hi Dave, three more fixes I would like to get to 4.5 still. It's getting late but I think these are still justified and these have been in linux-next almost a week. But if you think otherwise please let me know and I'll pull these to wireless-drivers-next instead. Kalle The following changes

[PATCH v3 10/19] x86, 64bit: Set ident_mapping for kaslr

From: Yinghai Lu Current aslr only support random in small range, from 16M to 1G. And new range still use old mapping. Also it does not support new range above 4G. We need to have ident mapping for the new range before we can do decompress to the new output, and later run

[PATCH v3 06/19] x86, kaslr: Clean up useless code related to run_size.

From: Yinghai Lu So now we use the below formula to get run_size. run_size = VO__end - VO__text Let's remove code for old run_size calculation and clean up the places where run_size need be passed in and out. Cc: "H. Peter Anvin" Cc: Josh Triplett Cc: Matt Fleming Cc: Kees Cook

[PATCH v3 08/19] x86, kaslr: Consolidate mem_avoid array filling

From: Yinghai Lu We are going to support kaslr with 64bit above 4G, and new random output could be anywhere. Array mem_avoid is used for kaslr to search new output address. Current code only track range that is after output+output_size. So we need to track all ranges instead of just after

[PATCH v3 07/19] x86, kaslr: Get correct max_addr for relocs pointer

From: Yinghai Lu There is boundary checking for pointer in kaslr relocation handling. Current code is using output_len, and that is VO (vmlinux after objcopy) file size plus vmlinux.relocs file size. That is not right, as we should use loaded address for running. At that time parse_elf

pull-request: wireless-drivers 2016-03-04

Hi Dave, three more fixes I would like to get to 4.5 still. It's getting late but I think these are still justified and these have been in linux-next almost a week. But if you think otherwise please let me know and I'll pull these to wireless-drivers-next instead. Kalle The following changes

[PATCH v3 10/19] x86, 64bit: Set ident_mapping for kaslr

From: Yinghai Lu Current aslr only support random in small range, from 16M to 1G. And new range still use old mapping. Also it does not support new range above 4G. We need to have ident mapping for the new range before we can do decompress to the new output, and later run them. In this patch,

[PATCH v3 11/19] x86, boot: Add checking for memcpy

From: Yinghai Lu parse_elf is using local memcpy to move section to running position. That memcpy actually only support no overlapping case or when dest < src. Add checking in memcpy to find out the wrong case for future use, at that time we will need to have backward memcpy

[PATCH v3 11/19] x86, boot: Add checking for memcpy

From: Yinghai Lu parse_elf is using local memcpy to move section to running position. That memcpy actually only support no overlapping case or when dest < src. Add checking in memcpy to find out the wrong case for future use, at that time we will need to have backward memcpy for it. Also add

[PATCH v3 05/19] x86, boot: Fix run_size calculation

From: Yinghai Lu Firstly, current run_size is calculated via shell script arch/x86/tools/calc_run_size.sh. It gets file offset and mem size of section .bss and .brk in vmlinux, then add them as follows: run_size=$(( $offsetA + $sizeA + $sizeB )) However this is completely

[PATCH v3 04/19] x86, kaskr: Update the description for decompressor worst case

Current analysis is only for gzip decompressor only. In fact we can support 6 different decompressor. Update the description to cover all of them. Meanwhile fix several typos. Signed-off-by: Baoquan He --- v2->v3: This is newly added. arch/x86/boot/compressed/misc.c | 26

[PATCH v3 03/19] x86, boot: Move z_extract_offset calculation to header.S

From: Yinghai Lu Current z_extract_offset is calculated in boot/compressed/mkpiggy.c. The problem is in mkpiggy.c we don't know the detail of decompressor. Then we just get a rough z_extract_offset according to extra_bytes. As we know extra_bytes can only promise a safety

[PATCH v3 05/19] x86, boot: Fix run_size calculation

From: Yinghai Lu Firstly, current run_size is calculated via shell script arch/x86/tools/calc_run_size.sh. It gets file offset and mem size of section .bss and .brk in vmlinux, then add them as follows: run_size=$(( $offsetA + $sizeA + $sizeB )) However this is completely wrong. The offset is

[PATCH v3 04/19] x86, kaskr: Update the description for decompressor worst case

Current analysis is only for gzip decompressor only. In fact we can support 6 different decompressor. Update the description to cover all of them. Meanwhile fix several typos. Signed-off-by: Baoquan He --- v2->v3: This is newly added. arch/x86/boot/compressed/misc.c | 26

[PATCH v3 03/19] x86, boot: Move z_extract_offset calculation to header.S

From: Yinghai Lu Current z_extract_offset is calculated in boot/compressed/mkpiggy.c. The problem is in mkpiggy.c we don't know the detail of decompressor. Then we just get a rough z_extract_offset according to extra_bytes. As we know extra_bytes can only promise a safety margin when

[PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support

***Background: Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region. This is because in curent kaslr implementaion only physical address of kernel loading is

[PATCH v3 00/19] x86, boot: kaslr cleanup and 64bit kaslr support

***Background: Previously a bug is reported that kdump didn't work when kaslr is enabled. During discussing that bug fix, we found current kaslr has a limilation that it can only randomize in 1GB region. This is because in curent kaslr implementaion only physical address of kernel loading is

[PATCH v3 02/19] x86, boot: Move compressed kernel to end of buffer before decompressing

From: Yinghai Lu For better understanding clarify what are VO and ZO firstly. They are introduced in below commits by hpa. 77d1a49 x86, boot: make symbols from the main vmlinux available 37ba7ab x86, boot: make kernel_alignment adjustable; new bzImage fields VO: -

[PATCH v3 02/19] x86, boot: Move compressed kernel to end of buffer before decompressing

From: Yinghai Lu For better understanding clarify what are VO and ZO firstly. They are introduced in below commits by hpa. 77d1a49 x86, boot: make symbols from the main vmlinux available 37ba7ab x86, boot: make kernel_alignment adjustable; new bzImage fields VO: - uncompressed kernel - size:

[PATCH v3 01/19] x86, kaslr: Remove not needed parameter for choose_kernel_location

From: Yinghai Lu real_mode is global variable, so we do not need to pass it around. Signed-off-by: Yinghai Lu --- arch/x86/boot/compressed/aslr.c | 5 ++--- arch/x86/boot/compressed/misc.c | 2 +- arch/x86/boot/compressed/misc.h | 6 ++ 3 files

[PATCH v3 01/19] x86, kaslr: Remove not needed parameter for choose_kernel_location

From: Yinghai Lu real_mode is global variable, so we do not need to pass it around. Signed-off-by: Yinghai Lu --- arch/x86/boot/compressed/aslr.c | 5 ++--- arch/x86/boot/compressed/misc.c | 2 +- arch/x86/boot/compressed/misc.h | 6 ++ 3 files changed, 5 insertions(+), 8 deletions(-)

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

On 04/03/2016 15:26, Li, Liang Z wrote: >> > >> > The memory usage will keep increasing due to ever growing caches, etc, so >> > you'll be left with very little free memory fairly soon. >> > > I don't think so. > Roman is right. For example, here I am looking at a 64 GB (physical) machine

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

On 04/03/2016 15:26, Li, Liang Z wrote: >> > >> > The memory usage will keep increasing due to ever growing caches, etc, so >> > you'll be left with very little free memory fairly soon. >> > > I don't think so. > Roman is right. For example, here I am looking at a 64 GB (physical) machine

Re: [PATCH] gpio: omap: drop dev field from gpio_bank structure

On 3/4/2016 7:25 AM, Grygorii Strashko wrote: GPIO chip structure already has "parent" field which is used for the same purpose as "dev" field in gpio_bank structure - store pointer on GPIO device. Hence, drop duplicated "dev" field from gpio_bank structure. Signed-off-by: Grygorii Strashko

Re: [PATCH] gpio: omap: drop dev field from gpio_bank structure

On 3/4/2016 7:25 AM, Grygorii Strashko wrote: GPIO chip structure already has "parent" field which is used for the same purpose as "dev" field in gpio_bank structure - store pointer on GPIO device. Hence, drop duplicated "dev" field from gpio_bank structure. Signed-off-by: Grygorii Strashko

[PATCH v10 6/9] dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding

From: Thierry Reding Add device-tree binding documentation for the XUSB controller present on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI compliant interface. Based on work by Andrew Bresticker . Cc: Rob Herring

[PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

From: Thierry Reding Add support for the on-chip XUSB controller present on Tegra SoCs. This controller, when loaded with external firmware, exposes an interface compliant with xHCI. This driver loads the firmware, starts the controller, and is able to service host-specific

[PATCH v10 6/9] dt-bindings: usb: Add NVIDIA Tegra XUSB controller binding

From: Thierry Reding Add device-tree binding documentation for the XUSB controller present on Tegra124 and later SoCs. This controller supports USB 3.0 via an xHCI compliant interface. Based on work by Andrew Bresticker . Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc:

[PATCH v10 8/9] usb: xhci: Add NVIDIA Tegra XUSB controller driver

From: Thierry Reding Add support for the on-chip XUSB controller present on Tegra SoCs. This controller, when loaded with external firmware, exposes an interface compliant with xHCI. This driver loads the firmware, starts the controller, and is able to service host-specific messages sent by the

[PATCH v10 7/9] dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support

From: Thierry Reding Extend the Tegra XUSB controller device tree binding with Tegra210 support. Signed-off-by: Thierry Reding --- .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 12 1 file changed, 12 insertions(+) diff

[PATCH v10 7/9] dt-bindings: usb: xhci-tegra: Add Tegra210 XUSB controller support

From: Thierry Reding Extend the Tegra XUSB controller device tree binding with Tegra210 support. Signed-off-by: Thierry Reding --- .../devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 12 1 file changed, 12 insertions(+) diff --git

[PATCH 2.6.32 26/55] udf: limit the maximum number of indirect extents in a row

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Vegard Nossum commit b0918d9f476a8434b055e362b83fa4fd1d462c3f upstream. udf_next_aext() just follows extent pointers while extents are marked as indirect. This

[PATCH 2.6.32 51/55] ALSA: usb-audio: avoid freeing umidi object twice

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Andrey Konovalov commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream. The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing

[PATCH v10 5/9] phy: tegra: Add Tegra210 support

From: Thierry Reding Add support for the XUSB pad controller found on Tegra210 SoCs. The hardware is roughly the same, but some of the registers have been moved around and the number and type of supported pads has changed. Signed-off-by: Thierry Reding

[PATCH 2.6.32 14/55] readv/writev: do the same MAX_RW_COUNT truncation that read/write does

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit 435f49a518c78eec8e2edbbadd912737246cbe20 upstream. We used to protect against overflow, but rather than return an error, do what

[PATCH 2.6.32 26/55] udf: limit the maximum number of indirect extents in a row

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Vegard Nossum commit b0918d9f476a8434b055e362b83fa4fd1d462c3f upstream. udf_next_aext() just follows extent pointers while extents are marked as indirect. This can loop forever for

[PATCH 2.6.32 51/55] ALSA: usb-audio: avoid freeing umidi object twice

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Andrey Konovalov commit 07d86ca93db7e5cdf4743564d98292042ec21af7 upstream. The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi

[PATCH v10 5/9] phy: tegra: Add Tegra210 support

From: Thierry Reding Add support for the XUSB pad controller found on Tegra210 SoCs. The hardware is roughly the same, but some of the registers have been moved around and the number and type of supported pads has changed. Signed-off-by: Thierry Reding --- Changes in v9: - expose more public

[PATCH 2.6.32 14/55] readv/writev: do the same MAX_RW_COUNT truncation that read/write does

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Linus Torvalds commit 435f49a518c78eec8e2edbbadd912737246cbe20 upstream. We used to protect against overflow, but rather than return an error, do what read/write does, namely to limit the

[PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

From: Thierry Reding The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a set of lanes that are used for PCIe, SATA and USB. Signed-off-by: Thierry Reding --- Changes in v10: - clarify that the hardware documentation means something

[PATCH v10 9/9] usb: xhci: tegra: Add Tegra210 support

From: Thierry Reding Parameterize more parts of the driver and add support for Tegra210. Cc: Greg Kroah-Hartman Cc: Mathias Nyman Signed-off-by: Thierry Reding --- drivers/usb/host/xhci-tegra.c | 59

[PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

From: Thierry Reding The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a set of lanes that are used for PCIe, SATA and USB. Signed-off-by: Thierry Reding --- Changes in v10: - clarify that the hardware documentation means something different when referring to a "port"

[PATCH v10 9/9] usb: xhci: tegra: Add Tegra210 support

From: Thierry Reding Parameterize more parts of the driver and add support for Tegra210. Cc: Greg Kroah-Hartman Cc: Mathias Nyman Signed-off-by: Thierry Reding --- drivers/usb/host/xhci-tegra.c | 59 +-- 1 file changed, 51 insertions(+), 8

[PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. Signed-off-by: Thierry Reding --- .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 327 + 1 file changed, 327 insertions(+) diff --git

[PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. Signed-off-by: Thierry Reding --- .../bindings/phy/nvidia,tegra124-xusb-padctl.txt | 327 + 1 file changed, 327 insertions(+) diff --git

[PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

From: Thierry Reding This is an old version of the binding that isn't flexible enough to describe all aspects of the XUSB pad controller. Specifically with the addition of XUSB support (for SuperSpeed USB) the existing binding is no longer suitable. Signed-off-by: Thierry

[PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

From: Thierry Reding Add a new driver for the XUSB pad controller found on NVIDIA Tegra SoCs. This hardware block used to be exposed as a pin controller, but it turns out that this isn't a good fit. The new driver and DT binding much more accurately describe the hardware and

[PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

From: Thierry Reding This is an old version of the binding that isn't flexible enough to describe all aspects of the XUSB pad controller. Specifically with the addition of XUSB support (for SuperSpeed USB) the existing binding is no longer suitable. Signed-off-by: Thierry Reding ---

[PATCH v10 4/9] phy: Add Tegra XUSB pad controller support

From: Thierry Reding Add a new driver for the XUSB pad controller found on NVIDIA Tegra SoCs. This hardware block used to be exposed as a pin controller, but it turns out that this isn't a good fit. The new driver and DT binding much more accurately describe the hardware and are more flexible in

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Added Tilman and Christoph.] On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote: > I actually did more patches that I ended up not submitting: > > * move hisax to staging > * remove i4l support from gigaset For the record: I have no reason to object a patch that does that. (I'm not aware

[PATCH 2.6.32 32/55] ALSA: hrtimer: Fix stall by hrtimer_cancel()

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream. hrtimer_cancel() waits for the completion from the callback, thus it must not be called inside the

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Added Tilman and Christoph.] On vr, 2016-03-04 at 16:24 +0100, Arnd Bergmann wrote: > I actually did more patches that I ended up not submitting: > > * move hisax to staging > * remove i4l support from gigaset For the record: I have no reason to object a patch that does that. (I'm not aware

[PATCH 2.6.32 32/55] ALSA: hrtimer: Fix stall by hrtimer_cancel()

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 2ba1fe7a06d3624f9a7586d672b55f08f7c670f3 upstream. hrtimer_cancel() waits for the completion from the callback, thus it must not be called inside the callback itself.

[PATCH 2.6.32 31/55] ALSA: timer: Harden slave timer list handling

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit b5a663aa426f4884c71cd8580adae73f33570f0d upstream. A slave timer instance might be still accessible in a racy way while operating the master instance as

[PATCH 2.6.32 49/55] ALSA: timer: Fix wrong instance passed to slave callbacks

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 117159f0b9d392fb433a7871426fad50317f06f7 upstream. In snd_timer_notify1(), the wrong timer instance was passed for slave ccallback function. This leads

[PATCH 2.6.32 31/55] ALSA: timer: Harden slave timer list handling

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit b5a663aa426f4884c71cd8580adae73f33570f0d upstream. A slave timer instance might be still accessible in a racy way while operating the master instance as it lacks of

[PATCH 2.6.32 49/55] ALSA: timer: Fix wrong instance passed to slave callbacks

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 117159f0b9d392fb433a7871426fad50317f06f7 upstream. In snd_timer_notify1(), the wrong timer instance was passed for slave ccallback function. This leads to the access

[PATCH 2.6.32 30/55] ALSA: dummy: Disable switching timer backend via sysfs

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 upstream. ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer

[PATCH 2.6.32 39/55] ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit cc85f7a634cfaf9f0713c6aa06d08817424db37a upstream. NULL user-space buffer can be passed even in a normal path, thus it's not good to spew a kernel

[PATCH 2.6.32 30/55] ALSA: dummy: Disable switching timer backend via sysfs

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 7ee96216c31aabe1eb42fb91ff50dae9fcd014b2 upstream. ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This

[PATCH 2.6.32 39/55] ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer check

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit cc85f7a634cfaf9f0713c6aa06d08817424db37a upstream. NULL user-space buffer can be passed even in a normal path, thus it's not good to spew a kernel warning with stack

[PATCH 2.6.32 12/55] l2tp: fix another panic in pppol2tp

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Willy Tarreau Commit 3feec9095d1 ("l2tp: Fix oops in pppol2tp_xmit") was backported into 2.6.32.16 to fix a possible null deref in pppol2tp. But the same still exists in

[PATCH 2.6.32 02/55] usbvision fix overflow of interfaces array

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Oliver Neukum commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream. This fixes the crash reported in: http://seclists.org/bugtraq/2015/Oct/35 The interface number

[PATCH 2.6.32 25/55] udf: Promote some debugging messages to udf_error

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Joe Perches commit 7e273e3b41e32716dc122b293b5f15635af495ff upstream. If there is a problem with a scratched disc or loader, it's valuable to know which error occurred.

[PATCH 2.6.32 12/55] l2tp: fix another panic in pppol2tp

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Willy Tarreau Commit 3feec9095d1 ("l2tp: Fix oops in pppol2tp_xmit") was backported into 2.6.32.16 to fix a possible null deref in pppol2tp. But the same still exists in pppol2tp_sendmsg()

[PATCH 2.6.32 02/55] usbvision fix overflow of interfaces array

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Oliver Neukum commit 588afcc1c0e45358159090d95bf7b246fb67565f upstream. This fixes the crash reported in: http://seclists.org/bugtraq/2015/Oct/35 The interface number needs a sanity

[PATCH 2.6.32 25/55] udf: Promote some debugging messages to udf_error

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Joe Perches commit 7e273e3b41e32716dc122b293b5f15635af495ff upstream. If there is a problem with a scratched disc or loader, it's valuable to know which error occurred. Convert some

[PATCH 2.6.32 48/55] ALSA: timer: Fix race among timer ioctls

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit af368027a49a751d6ff4ee9e3f9961f35bb4fede upstream. ALSA timer ioctls have an open race and this may lead to a use-after-free of timer instance object.

[PATCH 2.6.32 19/55] rfkill: fix rfkill_fop_read wait_event usage

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Johannes Berg commit 6736fde9672ff6717ac576e9bba2fd5f3dfec822 upstream. The code within wait_event_interruptible() is called with !TASK_RUNNING, so mustn't call

[PATCH 2.6.32 33/55] ALSA: pcm: Fix snd_pcm_hw_params struct copy in compat mode

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Nicolas Boichat commit 43c54b8c7cfe22f868a751ba8a59abf1724160b1 upstream. This reverts one hunk of commit ef44a1ec6eee ("ALSA: sound/core: use memdup_user()"),

[PATCH 2.6.32 16/55] af_unix: fix struct pid memory leak

2.6.32-longterm review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit fa0dc04df259ba2df3ce1920e9690c7842f8fa4b upstream. Dmitry reported a struct pid leak detected by a syzkaller program. Bug happens in

<    4   5   6   7   8   9   10   11   12   13   >