diff --git a/Makefile b/Makefile
index 5abb21c7d852..b18b61e540e9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 254
+SUBLEVEL = 255
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arm/mach-imx/suspend-imx6.S
I'm announcing the release of the 4.9.255 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index 494420ad33a1..f7f11304776b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 218
+SUBLEVEL = 219
EXTRAVERSION =
NAME = Petit Gorille
diff --git
I'm announcing the release of the 4.4.255 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
On Wed, Feb 03, 2021 at 12:42:58PM -0800, Guenter Roeck wrote:
> On Tue, Feb 02, 2021 at 02:36:03PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.13 release.
> > There are 142 patches in this series, all will be posted as a response
> > to this one.
On Tue, Feb 02, 2021 at 06:18:44PM +0100, Pavel Machek wrote:
> Hi!
>
> > This is the start of the stable review cycle for the 5.10.13 release.
> > There are 142 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
>
On 2/3/21 1:08 PM, Peter Xu wrote:
> Introduce hugetlb_resv_map_add() helper to add a new file_region rather than
> duplication the similar code twice in add_reservation_in_range().
>
> Signed-off-by: Peter Xu
> ---
> mm/hugetlb.c | 51 +++
> 1
From: "H.J. Lu"
Update ARCH_X86_CET_STATUS and ARCH_X86_CET_DISABLE for Indirect Branch
Tracking.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
---
arch/x86/kernel/cet_prctl.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/cet_prctl.c
From: "H.J. Lu"
Add ENDBR32 to __kernel_vsyscall entry point.
Signed-off-by: H.J. Lu
Signed-off-by: Yu-cheng Yu
Acked-by: Andy Lutomirski
---
arch/x86/entry/vdso/vdso32/system_call.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/entry/vdso/vdso32/system_call.S
Indirect branch tracking is a hardware security feature that verifies near
indirect call/jump instructions arrive at intended targets, which are
labeled by the compiler with ENDBR opcodes. If such instructions reach
unlabeled locations, the processor raises control-protection faults.
Check the
An ELF file's .note.gnu.property indicates features the file supports.
The property is parsed at loading time and passed to arch_setup_elf_
property(). Update it for Indirect Branch Tracking.
Signed-off-by: Yu-cheng Yu
---
arch/x86/kernel/process_64.c | 8
1 file changed, 8
On 2/3/21 2:00 PM, Joao Martins wrote:
Add an helper that iterates over head pages in a list of pages. It
essentially counts the tails until the next page to process has a
different head that the current. This is going to be used by
unpin_user_pages() family of functions, to batch the head page
arch_prctl(ARCH_X86_CET_STATUS, u64 *args)
Get CET feature status.
The parameter 'args' is a pointer to a user buffer. The kernel returns
the following information:
*args = shadow stack/IBT status
*(args + 1) = shadow stack base address
*(args + 2) = shadow stack size
There are three possible options to create a shadow stack allocation API:
an arch_prctl, a new syscall, or adding PROT_SHSTK to mmap()/mprotect().
Each has its advantages and compromises.
An arch_prctl() is the least intrusive. However, the existing x86
arch_prctl() takes only two parameters.
On 2/3/21 3:06 PM, Greg Kroah-Hartman wrote:
> On Wed, Feb 03, 2021 at 01:28:26PM -0800, Andres Freund wrote:
>> Hi,
>>
>> On 2021-02-03 14:03:09 +0100, Greg Kroah-Hartman wrote:
On v5.4.43-101-gbba91cdba612 this fails with
fio: io_u error on file /mnt/t2/test.0.0: Input/output error:
To deliver a signal, create a shadow stack restore token and put the token
and the signal restorer address on the shadow stack. For sigreturn, verify
the token and restore from it the shadow stack pointer.
A shadow stack restore token marks a restore point of the shadow stack.
The token is
There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:
commit 45e55300f114 ("mm: remove unnecessary wrapper function
do_mmap_pgoff()").
There is a new user now. Shadow stack allocation passes VM_SHSTK to
do_mmap(). Re-introduce
Introduce basic shadow stack enabling/disabling/allocation routines.
A task's shadow stack is allocated from memory with VM_SHSTK flag and has
a fixed size of min(RLIMIT_STACK, 4GB).
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/cet.h | 28 ++
arch/x86/include/asm/processor.h |
When serving a page fault, maybe_mkwrite() makes a PTE writable if it is in
a writable vma. A shadow stack vma is writable, but its PTEs need
_PAGE_DIRTY to be set to become writable. For this reason, maybe_mkwrite()
has been updated.
There are a few places that call pte_mkwrite() directly, but
Account shadow stack pages to stack memory.
Signed-off-by: Yu-cheng Yu
---
arch/x86/mm/pgtable.c | 7 +++
include/linux/pgtable.h | 11 +++
mm/mmap.c | 5 +
3 files changed, 23 insertions(+)
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index
When Shadow Stack is introduced, [R/O + _PAGE_DIRTY] PTE is reserved for
shadow stack. Copy-on-write PTEs have [R/O + _PAGE_COW].
When a PTE goes from [R/W + _PAGE_DIRTY] to [R/O + _PAGE_COW], it could
become a transient shadow stack PTE in two cases:
The first case is that some processors can
The read-only and Dirty PTE has been used to indicate copy-on-write pages.
However, newer x86 processors also regard a read-only and Dirty PTE as a
shadow stack page. In order to separate the two, the software-defined
_PAGE_COW is created to replace _PAGE_DIRTY for the copy-on-write case, and
Shadow stack accesses are those that are performed by the CPU where it
expects to encounter a shadow stack mapping. These accesses are performed
implicitly by CALL/RET at the site of the shadow stack pointer. These
accesses are made explicitly by shadow stack management instructions like
WRUSSQ.
A shadow stack PTE must be read-only and have _PAGE_DIRTY set. However,
read-only and Dirty PTEs also exist for copy-on-write (COW) pages. These
two cases are handled differently for page faults. Introduce VM_SHSTK to
track shadow stack VMAs.
Signed-off-by: Yu-cheng Yu
Reviewed-by: Kees Cook
There is essentially no room left in the x86 hardware PTEs on some OSes
(not Linux). That left the hardware architects looking for a way to
represent a new memory type (shadow stack) within the existing bits.
They chose to repurpose a lightly-used state: Write=0, Dirty=1.
The reason it's lightly
The x86 family of processors do not directly create read-only and Dirty
PTEs. These PTEs are created by software. One such case is that kernel
read-only pages are historically setup as Dirty.
New processors that support Shadow Stack regard read-only and Dirty PTEs as
shadow stack pages. This
Control-flow Enforcement (CET) is a new Intel processor feature that blocks
return/jump-oriented programming attacks. Details are in "Intel 64 and
IA-32 Architectures Software Developer's Manual" [1].
CET can protect applications and the kernel. This series enables only
application-level
Shadow Stack provides protection against function return address
corruption. It is active when the processor supports it, the kernel has
CONFIG_X86_CET enabled, and the application is built for the feature.
This is only implemented for the 64-bit kernel. When it is enabled, legacy
non-Shadow
A control-protection fault is triggered when a control-flow transfer
attempt violates Shadow Stack or Indirect Branch Tracking constraints.
For example, the return address for a RET instruction differs from the copy
on the shadow stack; or an indirect JMP instruction, without the NOTRACK
prefix,
Add CPU feature flags for Control-flow Enforcement Technology (CET).
CPUID.(EAX=7,ECX=0):ECX[bit 7] Shadow stack
CPUID.(EAX=7,ECX=0):EDX[bit 20] Indirect Branch Tracking
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/cpufeatures.h | 2 ++
arch/x86/include/asm/disabled-features.h |
Introduce a software-defined X86_FEATURE_CET, which indicates either Shadow
Stack or Indirect Branch Tracking (or both) is present. Also introduce
related cpu init/setup functions.
Signed-off-by: Yu-cheng Yu
---
arch/x86/include/asm/cpufeatures.h | 2 +-
On 2/3/21 1:01 AM, Wu, Hao wrote:
>> Subject: [PATCH v3 1/1] fpga: dfl: afu: harden port enable logic
>>
>> Port enable is not complete until ACK = 0. Change
>> __afu_port_enable() to guarantee that the enable process
>> is complete by polling for ACK == 0.
>>
>> Signed-off-by: Russ Weight
>>
On 2/3/21 1:28 AM, Wu, Hao wrote:
>> Subject: Re: [PATCH v2 1/1] fpga: dfl: afu: harden port enable logic
>>
>> Sorry for the delay on this patch. It seemed like a lower priority patch than
>> others, since we haven't seen any issues with current products. Please my
>> responses inline.
>>
>>
From: Kan Liang
Current perf assumes that the ENODATA is a unique error code for the
auxiliary event on Sapphire Rapids. The assumption is good for now, but
this is fragile. In the future, someone may not remember that the
ENODATA is for the auxiliary event on Sapphire Rapids, and reuse it for
On Wed, Feb 3, 2021 at 11:05 AM Josh Poimboeuf wrote:
>
> On Wed, Feb 03, 2021 at 09:46:55AM -0800, Ivan Babrou wrote:
> > > Can you pretty please not line-wrap console output? It's unreadable.
> >
> > GMail doesn't make it easy, I'll send a link to a pastebin next time.
> > Let me know if you'd
On 2021-02-03 2:17 p.m., Greg Kroah-Hartman wrote:
> On Wed, Feb 03, 2021 at 01:04:51PM -0800, Scott Branden wrote:
>> Correct compile issue if CONFIG_TTY is not set by
>> only adding ttyVK devices if CONFIG_BCM_VK_TTY is set.
>>
>> Reported-by: Randy Dunlap
>> Signed-off-by: Scott Branden
>>
Correct compile issue if CONFIG_TTY is not set by
only adding ttyVK devices if CONFIG_BCM_VK_TTY is set.
Reported-by: Randy Dunlap
Signed-off-by: Scott Branden
---
Changes since v3:
- Kconfig cleanups below as per Greg's comments
- changed if BCM_VK to depends on BCM_VK
- removed default y in
On Wed, 3 Feb 2021 15:56:20 -0600
Timur Tabi wrote:
> On 2/3/21 2:47 PM, Steven Rostedt wrote:
> > static void __init
> > plain(void)
> > {
> > int err;
> >
> > + if (debug_never_hash_pointers)
> > + return;
>
> So, I have a stupid question. What's the best way for
> > After the most recent build errors, I tried to apply Pavel's patch
> >
> > https://lore.kernel.org/linux-mm/CA+CK2bBjC8=crsl5vhwkcevpsqsxwhsanvjsfnmerlt8vwt...@mail.gmail.com/
> > but patch said that it was already applied (by Andrew I think),
> > so I bailed out (gave up).
>
> As far as I
From: Ira Weiny
In dump_user_range() there is no reason for the mapping to be global.
Use kmap_local_page() rather than kmap.
Cc: Andrew Morton
Cc: linux-kernel@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Ira Weiny
---
fs/coredump.c | 4 ++--
1 file changed, 2
Hi
> > > > +int graph_remove(struct platform_device *pdev);
>
> > > I think this needs better namespacing if it's going to be exported.
>
> > audio_graph_remove() can be a better choice?
>
> Yeah, that looks reasonable.
Nice naming I think.
In such case, update also graph_parse_of() is
On Wed, Feb 03, 2021 at 11:12:46PM +0100, Gustavo Pimentel wrote:
> + /* Sysfs */
> + err = sysfs_create_group(>dev.kobj, _attr_group);
> + if (err)
> + return err;
> +
> + err = sysfs_create_link(kernel_kobj, >dev.kobj,
> +
Hi Sameer
> Audio graph based sound card drivers can call graph_remove() function
> for cleanups during driver removal. To facilitate this export above
> mentioned function.
>
> Signed-off-by: Sameer Pujar
> Cc: Kuninori Morimoto
(snip)
> -static int graph_remove(struct platform_device
On Wed, Feb 03, 2021 at 02:04:30PM -0800, Mike Kravetz wrote:
> > @@ -3816,6 +3832,54 @@ int copy_hugetlb_page_range(struct mm_struct *dst,
> > struct mm_struct *src,
> > }
> > set_huge_swap_pte_at(dst, addr, dst_pte, entry, sz);
> > } else {
>
On 2/3/2021 2:11 PM, Dave Hansen wrote:
On 2/3/21 1:54 PM, Yu, Yu-cheng wrote:
On 1/29/2021 10:56 AM, Yu, Yu-cheng wrote:
On 1/29/2021 9:07 AM, Dave Hansen wrote:
On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
+ if (!IS_ENABLED(CONFIG_X86_CET))
+ return -EOPNOTSUPP;
Let's ignore glibc
On Thu, Feb 4, 2021 at 7:23 AM Masahiro Yamada wrote:
>
> On Sat, Jan 30, 2021 at 10:52 AM Nathan Chancellor wrote:
> >
> > On Fri, Jan 29, 2021 at 04:44:00PM -0800, Nick Desaulniers wrote:
> > > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is
> > > the default. Does so in
On Wed, Feb 03, 2021 at 11:12:48PM +0100, Gustavo Pimentel wrote:
> Add Synopsys DesignWare xData IP driver to Kconfig.
>
> This driver enables/disables the PCIe traffic generator module
> pertain to the Synopsys DesignWare prototype.
>
> Signed-off-by: Gustavo Pimentel
> ---
>
On Wed, Feb 03, 2021 at 11:12:48PM +0100, Gustavo Pimentel wrote:
> Add Synopsys DesignWare xData IP driver to Kconfig.
>
> This driver enables/disables the PCIe traffic generator module
> pertain to the Synopsys DesignWare prototype.
>
> Signed-off-by: Gustavo Pimentel
> ---
>
On Sat, Jan 30, 2021 at 10:52 AM Nathan Chancellor wrote:
>
> On Fri, Jan 29, 2021 at 04:44:00PM -0800, Nick Desaulniers wrote:
> > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is
> > the default. Does so in a way that's forward compatible with existing
> > configs, and
>> I have applied the following patch for today:
> >>
> >> From: Stephen Rothwell
> >> Date: Tue, 2 Feb 2021 19:49:00 +1100
> >> Subject: [PATCH] make is_pinnable_page a macro
> >>
> >> As it is currently defined before page_to_section(
On Wed, Feb 03, 2021 at 01:04:51PM -0800, Scott Branden wrote:
> Correct compile issue if CONFIG_TTY is not set by
> only adding ttyVK devices if CONFIG_BCM_VK_TTY is set.
>
> Reported-by: Randy Dunlap
> Signed-off-by: Scott Branden
>
> ---
> Changes since v3:
Is this "v4"? Your subject line
On Thu, Feb 04, 2021 at 12:35:42AM +0300, Pavel Tikhomirov wrote:
>
> AFAICS if pid is held only by 1) fowner refcount and by 2) single process
> (without threads, group and session for simplicity), on process exit we go
> through:
>
> do_exit
> exit_notify
> release_task
>
Add Synopsys DesignWare xData IP driver to Makefile.
This driver enables/disables the PCIe traffic generator module
pertain to the Synopsys DesignWare prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/Makefile
Add Synopsys DesignWare xData IP driver to Kconfig.
This driver enables/disables the PCIe traffic generator module
pertain to the Synopsys DesignWare prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git
This patch describes the sysfs interface implemented on the dw-xdata-pcie
driver.
Signed-off-by: Gustavo Pimentel
---
Documentation/ABI/testing/sysfs-driver-xdata | 46
1 file changed, 46 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-xdata
This patch series adds a new driver called xData-pcie for the Synopsys
DesignWare PCIe prototype.
The driver configures and enables the Synopsys DesignWare PCIe traffic
generator IP inside of prototype Endpoint which will generate upstream
and downstream PCIe traffic. This allows to quickly test
Add Documentation for dw-xdata-pcie driver.
Signed-off-by: Gustavo Pimentel
---
Documentation/misc-devices/dw-xdata-pcie.rst | 40
1 file changed, 40 insertions(+)
create mode 100644 Documentation/misc-devices/dw-xdata-pcie.rst
diff --git
Add Synopsys xData IP driver maintainer.
This driver aims to support Synopsys xData IP and is normally distributed
along with Synopsys PCIe EndPoint IP as a PCIe traffic generator (depends
of the use and licensing agreement).
Signed-off-by: Gustavo Pimentel
---
MAINTAINERS | 7 +++
1 file
Add Synopsys DesignWare xData IP driver. This driver enables/disables
the PCI traffic generator module pertain to the Synopsys DesignWare
prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/dw-xdata-pcie.c | 378 +++
1 file changed, 378
On Wed, Feb 3, 2021 at 1:46 PM Will Deacon wrote:
>
> On Tue, Feb 02, 2021 at 11:56:27AM +0530, Sai Prakash Ranjan wrote:
> > On 2021-02-01 23:50, Jordan Crouse wrote:
> > > On Mon, Feb 01, 2021 at 08:20:44AM -0800, Rob Clark wrote:
> > > > On Mon, Feb 1, 2021 at 3:16 AM Will Deacon wrote:
> > >
On 2/3/21 1:54 PM, Yu, Yu-cheng wrote:
> On 1/29/2021 10:56 AM, Yu, Yu-cheng wrote:
>> On 1/29/2021 9:07 AM, Dave Hansen wrote:
>>> On 1/27/21 1:25 PM, Yu-cheng Yu wrote:
+ if (!IS_ENABLED(CONFIG_X86_CET))
+ return -EOPNOTSUPP;
>>>
>>> Let's ignore glibc for a moment. What
On Wed, Feb 3, 2021 at 1:58 PM Stephen Boyd wrote:
>
> Quoting Rob Clark (2021-02-03 09:29:09)
> > On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> > >
> > > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > > > >
> >
Gustavo Pimentel writes:
> Add Documentation for dw-xdata-pcie driver.
>
> Signed-off-by: Gustavo Pimentel
> ---
> Documentation/misc-devices/dw-xdata-pcie.rst | 40
>
> 1 file changed, 40 insertions(+)
> create mode 100644
On Wed, Feb 03, 2021 at 01:15:03PM -0800, Linus Torvalds wrote:
> On Wed, Feb 3, 2021 at 1:08 PM Peter Xu wrote:
> >
> > This is the last missing piece of the COW-during-fork effort when there're
> > pinned pages found. One can reference 70e806e4e645 ("mm: Do early cow for
> > pinned pages
Add support for the HDMA feature.
This new feature enables the current eDMA IP to use a deeper prefetch
of the linked list, which reduces the algorithm execution latency
observed when loading the elements of the list, causing more stable
and higher data transfer.
Signed-off-by: Gustavo Pimentel
Add pci_find_vsec_capability() that crawls through the device config
space searching in all Vendor-Specific Extended Capabilities for a
particular capability ID.
Vendor-Specific Extended Capability (VSEC) is a PCIe capability (acts
like a wrapper) specified by PCI-SIG that allows the vendor to
Fix comments offset characters' alignment to follow the same structure
of similar comments.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-v0-regs.h | 214 +-
1 file changed, 107 insertions(+), 107 deletions(-)
diff --git
The latest eDMA IP development implements a Vendor-Specific Extended
Capability that contains the eDMA BAR, offset, map format, and the
number of read/write channels available.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 20 ---
Add device_prep_interleave_dma() support to Synopsys DMA driver.
This feature implements a similar data transfer mechanism to the
scatter-gather implementation.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 85 ++
On Wed, Feb 03, 2021 at 01:28:26PM -0800, Andres Freund wrote:
> Hi,
>
> On 2021-02-03 14:03:09 +0100, Greg Kroah-Hartman wrote:
> > > On v5.4.43-101-gbba91cdba612 this fails with
> > > fio: io_u error on file /mnt/t2/test.0.0: Input/output error: write
> > > offset=0, buflen=4096
> > > fio:
Add Synopsys xData IP driver maintainer.
This driver aims to support Synopsys xData IP and is normally distributed
along with Synopsys PCIe EndPoint IP as a PCIe traffic generator (depends
of the use and licensing agreement).
Signed-off-by: Gustavo Pimentel
---
MAINTAINERS | 7 +++
1 file
On Mon, Feb 1, 2021 at 10:06 PM Masahiro Yamada wrote:
>
> For the same reason as commit 51839e29cb59 ("scripts: switch explicitly
> to Python 3"), switch some more scripts, which I tested and confirmed
> working on Python 3.
>
> Signed-off-by: Masahiro Yamada
> Acked-by: Nathan Chancellor
Add Synopsys DesignWare xData IP driver to Kconfig.
This driver enables/disables the PCIe traffic generator module
pertain to the Synopsys DesignWare prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/Kconfig | 11 +++
1 file changed, 11 insertions(+)
diff --git
Add Synopsys DesignWare xData IP driver. This driver enables/disables
the PCI traffic generator module pertain to the Synopsys DesignWare
prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/dw-xdata-pcie.c | 378 +++
1 file changed, 378
On 2/3/21 1:08 PM, Peter Xu wrote:
> This is the last missing piece of the COW-during-fork effort when there're
> pinned pages found. One can reference 70e806e4e645 ("mm: Do early cow for
> pinned pages during fork() for ptes", 2020-09-27) for more information, since
> we do similar things here
This patch describes the sysfs interface implemented on the dw-xdata-pcie
driver.
Signed-off-by: Gustavo Pimentel
---
Documentation/ABI/testing/sysfs-driver-xdata | 46
1 file changed, 46 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-xdata
Add Synopsys DesignWare xData IP driver to Makefile.
This driver enables/disables the PCIe traffic generator module
pertain to the Synopsys DesignWare prototype.
Signed-off-by: Gustavo Pimentel
---
drivers/misc/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/Makefile
On Wed, Feb 3, 2021 at 1:58 PM Martin Kaiser wrote:
>
> Thus wrote Saravana Kannan (sarava...@google.com):
>
> > > With modules disabled, the kernel boots but probe fails for some
> > > (non-mainline) drivers in my tree.
>
> > Thanks Martin!
>
> > > All of those drivers have a gpio in
> > > their
On 2/3/21 1:06 PM, Linus Torvalds wrote:
On Wed, Feb 3, 2021 at 11:58 AM Shuah Khan wrote:
ld: arch/x86/built-in.a: member arch/x86/kernel/pci-swiotlb.o in archive
is not an object
make: *** [Makefile:1170: vmlinux] Error 1
That honestly sounds like something went wrong earlier - things
Add Documentation for dw-xdata-pcie driver.
Signed-off-by: Gustavo Pimentel
---
Documentation/misc-devices/dw-xdata-pcie.rst | 40
1 file changed, 40 insertions(+)
create mode 100644 Documentation/misc-devices/dw-xdata-pcie.rst
diff --git
This patch series adds a new driver called xData-pcie for the Synopsys
DesignWare PCIe prototype.
The driver configures and enables the Synopsys DesignWare PCIe traffic
generator IP inside of prototype Endpoint which will generate upstream
and downstream PCIe traffic. This allows to quickly test
Hey,
This series improves page unpinning, with an eye on improving MR
deregistration for big swaths of memory (which is bound by the page
unpining), particularly:
1) Decrement the head page by @ntails and thus reducing a lot the number of
atomic operations per compound page. This is done by
Thus wrote Geert Uytterhoeven (ge...@linux-m68k.org):
> > The property you are using is not a standard GPIO binding (-gpios,
> > gpio, gpios) and I'm not surprised it's not working. The gpio1 is
> > probably getting probe deferred and ends up running after "my_driver".
> So my_driver doesn't
Add a unpin_user_page_range() API which takes a starting page
and how many consecutive pages we want to dirty.
Given that we won't be iterating on a list of changes, change
compound_next() to receive a bool, whether to calculate from the starting
page, or walk the page array. Finally add a
Rather than decrementing the head page refcount one by one, we
walk the page array and checking which belong to the same
compound_head. Later on we decrement the calculated amount
of references in a single write to the head page. To that
end switch to for_each_compound_head() does most of the
In the driver code structure, I tried to keep the code style consistency
by writing the write channels instructions first, and then follow by the
read channels instructions, mimicking the hardware implementation.
However, this code style failed in some cases. This patch fixes that and
no
Add an helper that iterates over head pages in a list of pages. It
essentially counts the tails until the next page to process has a
different head that the current. This is going to be used by
unpin_user_pages() family of functions, to batch the head page refcount
updates once for all passed
Use the newly added unpin_user_page_range_dirty_lock()
for more quickly unpinning a consecutive range of pages
represented as compound pages. This will also calculate
number of pages to unpin (for the tail pages which matching
head page) and thus batch the refcount update.
Running a test program
In the previous implementation the driver assumes that only existed 2
memory spaces that would be equal distributed amount the write/read
channels.
This might not be the case on some other implementations, therefore this
patches changes this requirement so that each write/read channel has
their
It was added some extra checks to ensure that the driver doesn't try to
use more DMA channels than actually are available in hardware.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 21 +
drivers/dma/dw-edma/dw-edma-core.h | 2 ++
2 files changed,
Changes the linked list and data blocks offset and sizes to follow the
recommendation given by the hardware team for the IPK solution.
Although the previous data blocks offset and sizes are still valid and
functional, using them that might present some issues related to the IPK
solution, since
When the driver is compiled as a module and loaded if we try to unload
it, the Kernel shows a crash log. This Kernel crash is due to the
dma_async_device_unregister() call done after deleting the channels,
this patch fixes this issue.
Signed-off-by: Gustavo Pimentel
---
Reverting the applied patch because it caused a regression on
ARC700 platform (32 bits).
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c
This patch series adds the HDMA support, as long the IP design has set
the compatible register map parameter, which allows compatibility at
some degree for the existing Synopsys DesignWare eDMA driver that is
already available on the Kernel.
The HDMA "Hyper-DMA" IP is an enhancement of the eDMA
To keep code consistent, some comments with dma keyword written in lower
case are now in upper case.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/dw-edma/dw-edma-core.c
Move struct dentry variable from static definition (dw-edma-v0-debugfs.c)
into dw_edma struct (dw-edma-core.h)
Also the variable was renamed from base_dir to debugfs.
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-core.c | 2 +-
drivers/dma/dw-edma/dw-edma-core.h
Detected by CoverityScan CID 16555 ("Dereference null return")
Signed-off-by: Gustavo Pimentel
---
drivers/dma/dw-edma/dw-edma-pcie.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/dma/dw-edma/dw-edma-pcie.c
b/drivers/dma/dw-edma/dw-edma-pcie.c
index
Add writeq() and readq() for 64 bits architures support.
Supporting these two functions will allow the write or the read of eDMA
64 bits registers at once instead of having two consecutive operations.
Also, this improvement will allow the PCI optimization transaction
messages, which will
Quoting Rob Clark (2021-02-03 09:29:09)
> On Wed, Feb 3, 2021 at 2:10 AM Daniel Vetter wrote:
> >
> > On Tue, Feb 02, 2021 at 08:51:25AM -0800, Rob Clark wrote:
> > > On Tue, Feb 2, 2021 at 7:46 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Jan 25, 2021 at 03:49:01PM -0800, Stephen Boyd wrote:
Thus wrote Saravana Kannan (sarava...@google.com):
> > With modules disabled, the kernel boots but probe fails for some
> > (non-mainline) drivers in my tree.
> Thanks Martin!
> > All of those drivers have a gpio in
> > their device-tree node, such as
> > my_driver {
> >gpio_test1 = < 0
401 - 500 of 1611 matches
Mail list logo
