With this change a SPI controller can be added without having a IRQ
associated, and causing all transfers to be polled. For SPI controllers
without DMA, this can significantly improve performance by less
interrupt handling overhead.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
This add spi-nor device nodes to the Sparx5 reference boards.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 5 +++--
arch/arm64/boot/dts/microchip/sparx5_pcb125.dts| 9 +
arch/arm64/boot/dts/microchip/spar
This adds a SPI controller to the Microchip Sparx5 SoC
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
b/arch/arm64/boot/dts/
This add support for the RX_SAMPLE_DLY register. If enabled in the
Designware IP, it allows tuning of the rx data signal by means of an
internal rx sample fifo.
The register is located at offset 0xf0, and if the option is not
enabled in the IP, changing the register will have no effect.
Reviewed-
This patch add spi-nand DT nodes to the applicable Sparx5 boards.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 20
.../boot/dts/microchip/sparx5_pcb125.dts | 7 ++
.../boot/dts/microchip/sparx5_pcb134.d
This minor change allow dw-spi drivers to register
spi_controller_mem_ops memory operations if the platform supports it.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
drivers/spi/spi-dw.c | 3 +++
drivers/spi/spi-dw.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/drive
This adds support for the Sparx5 SoC in the spi-dw-mchp SPI controller.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
drivers/spi/spi-dw-mchp.c | 211 ++
1 file changed, 189 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-dw-mchp
This patch spins off the MSCC platforms into a separate driver, as
adding new platforms from the MSCC/Microchip product lines will
further complicate (clutter) the original driver.
The new 'spi-dw-mchp' driver still builds on the dw-spi foundation.
Reviewed-by: Alexandre Belloni
Signed-off-by: L
This add DT bindings for the Microsemi/Microchip SPI controller used
in various SoC's. It describes the "mscc,ocelot-spi" and
"mscc,jaguar2-spi" bindings.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
.../bindings/spi/mscc,ocelot-spi.yaml | 60 +++
.../b
This is an add-on series to the main SoC Sparx5 series
(Message-ID: <20200513125532.24585-1-lars.povl...@microchip.com>).
The series add support for Sparx5 on top of the existing
ocelot/jaguar2 spi driver.
It spins off the existing support for the MSCC platforms into a
separate driver, as adding
On Wed, 13 May 2020 at 15:24, Peter Zijlstra wrote:
>
> On Wed, May 13, 2020 at 03:15:55PM +0200, Marco Elver wrote:
> > So far so good, except: both __no_sanitize_or_inline and
> > __no_kcsan_or_inline *do* avoid KCSAN instrumenting plain accesses, it
> > just doesn't avoid explicit kcsan_check c
HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is
identified as a Revision B device as described in device identification
registers. In order to use this phy in the unmanaged mode, it requires
a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin
as document
The GEMGXL_RST line on HiFive Unleashed is pulled low and is
using GPIO number 12. Add these reset-gpio details to dt-node
using which the linux phylib can reset the phy.
Signed-off-by: Sagar Shrikant Kadam
---
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 +
1 file changed, 1 insertio
HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a
specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode.
This series addresses a corner case where phy reset is not handled by boot
stages prior to linux.
Somewhat similar unreliable phy probe failure was repor
Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line
connected to a gpio, so enable GPIO driver's required to reset
the phy.
Signed-off-by: Sagar Shrikant Kadam
---
arch/riscv/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/configs/defconfig b/arch/ri
Although not exactly identical, unthrottle_cfs_rq() and enqueue_task_fair()
are quite close and follow the same sequence for enqueuing an entity in the
cfs hierarchy. Modify unthrottle_cfs_rq() to use the same pattern as
enqueue_task_fair(). This fixes a problem already faced with the latter and
ad
enqueue_task_fair jumps to enqueue_throttle label when cfs_rq_of(se) is
throttled which means that se can't be NULL in such case and we can move
the label after the if (!se) statement. Futhermore, the latter can be
removed because se is always NULL when reaching this point.
Reviewed-by: Phil Auld
On Wed, May 13, 2020 at 02:46:31PM +0100, Jon Hunter wrote:
>
> On 13/05/2020 10:43, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.6.13 release.
> > There are 118 patches in this series, all will be posted as a response
> > to this one. If anyone has any iss
On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa wrote:
> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.
Why don't you look into having a "n
Balbir Singh writes:
> +++ b/arch/x86/kernel/l1d_flush.c
> @@ -0,0 +1,36 @@
Lacks
+// SPDX-License-Identifier: GPL-2.0-only
On Wed, May 13, 2020 at 11:03:48AM +0200, Vitaly Kuznetsov wrote:
> Vivek Goyal writes:
>
> > On Tue, May 12, 2020 at 05:50:53PM +0200, Vitaly Kuznetsov wrote:
> >> Vivek Goyal writes:
> >>
> >> >
> >> > So if we are using a common structure "kvm_vcpu_pv_apf_data" to deliver
> >> > type1 and ty
On Wed, May 13, 2020 at 03:32:09PM +0200, Andrew Lunn wrote:
> On Wed, May 13, 2020 at 02:06:48PM +0200, Oleksij Rempel wrote:
> > The cable test seems to be support by all of currently support Atherso
> > PHYs, so add support for all of them. This patch was tested only on
> > AR9331 PHY with follo
> So, I think consistency of implementation is more important than fixing
> this; the current behaviour has been established for many years now.
Hi Russell, Doug
With netlink ethtool we have the possibility of adding a new API to
control this. And we can leave the IOCTL API alone, and the current
On Wed, May 13, 2020 at 12:22 PM Christoph Hellwig wrote:
>
> On Wed, May 13, 2020 at 09:07:43AM +0200, Martijn Coenen wrote:
> > On Wed, May 13, 2020 at 4:30 AM Jens Axboe wrote:
> > > > Looks acceptable to me, but I'm getting a failure applying it to
> > > > for-5.8/drivers on this patch:
> > >
On 5/13/20 3:54 PM, ansuels...@gmail.com wrote:
>> Hi Ansuel,
>>
>> On 5/1/20 1:06 AM, Ansuel Smith wrote:
>>> From: Sham Muthayyan
>>>
>>> Add tx term offset support to pcie qcom driver need in some revision of
>>> the ipq806x SoC.
>>> Ipq8064 have tx term offset set to 7.
>>> Ipq8064-v2 revis
Hi Daniel
On Thu, 2020-05-07 at 13:06 +0200, Daniel Kiper wrote:
> > There is a function that verifies if platform is TXT capable
> > -grub_txt_verify_platform(), it only checks SMX and GETSEC features.
> > Although BIOS should enforce both VMX and VT-d enabled when enabling
> > TXT, I think that
I've pushed out a branch with the first three patches here:
git://git.infradead.org/users/hch/dma-mapping.git dma-sg_table-helper
Gitweb:
http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-sg_table-helper
and merged it into the dma-mapping for-next tree. Unless s
On 13/05/2020 10:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.41 release.
> There are 90 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 sho
On 13/05/2020 10:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.6.13 release.
> There are 118 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 sh
On Wed, 13 May 2020 20:03:53 +0900
Tetsuo Handa wrote:
> I think that basically only oops (e.g. WARN()/BUG()/panic()) messages worth
> printing to consoles and the rest messages do not worth printing to consoles.
> Existing KERN_$LOGLEVEL is too rough-grained.
And this statement is exactly why I
On 13/05/2020 10:44, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.123 release.
> There are 48 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 s
CC dt
On Wed, May 13, 2020 at 1:52 PM Rodrigo Rolim Mendes de Alencar
<455.rodrigo.alen...@gmail.com> wrote:
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
>
> Signed-off-by: Rodrigo Ale
Luis Chamberlain writes:
> On Tue, May 12, 2020 at 12:40:55PM -0500, Eric W. Biederman wrote:
>> Luis Chamberlain writes:
>>
>> > On Tue, May 12, 2020 at 06:52:35AM -0500, Eric W. Biederman wrote:
>> >> Luis Chamberlain writes:
>> >>
>> >> > +static struct ctl_table fs_base_table[] = {
>> >>
On Wed, May 13, 2020 at 03:38:36PM +0200, Martijn Coenen wrote:
> sector_t is now always u64, so we don't need to check for truncation.
>
> Signed-off-by: Martijn Coenen
Looks good:
Reviewed-by: Christoph Hellwig
On Wed, May 13, 2020 at 2:57 PM Kalle Valo wrote:
>
> Arnd Bergmann writes:
>
> > On Wed, May 13, 2020 at 8:50 AM Kalle Valo wrote:
> >>
> >> Kalle Valo writes:
> >
> > At least if it fails reproducibly, it's probably not too hard to drill
> > down further. Some ideas:
> >
> > * I'd first try t
On 2020/5/12 下午11:49, Qi Zheng wrote:
For version 1 to 3 of the device tree, this is the node full
path as a zero terminated string, starting with "/". The
following equation will not hold, since the node name has
been processed in the fdt_get_name().
*pathp == '/'
For version 16 and la
From: John Mathew
Add new sections to enable addition of new documentation on
the scheduler. Existing documentation is moved under the related
new sections. The sections are
- overview
- sched-features
- arch-specific.rst
- sched-debugging.rst
Suggested-by: Lukas Bulwahn
Signed-off-by:
version 4:
-Added section on Capacity-Aware Scheduling
-Reworded CFS recently added features.
-Removed vruntime description from scheduler structs
-Added description of idle and stopper sched classses
version 3:
-Fix spelling, spacing and typo errors.
version 2:
- Remove :c:func: directive a
From: John Mathew
Add documentation for introduction to
-context-switch
-x86 context-switch
-MIPS context switch
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa Chamanara
Co-developed-by: Oleg Tsymbal
Signed-off-by: Oleg Tsymbal
Signed-off-by: John M
---
Documentation/scheduler/cfs-overview.rst | 113 ++--
Documentation/scheduler/sched-cas.rst | 74
.../scheduler/sched-data-structs.rst | 163 +-
Documentation/scheduler/sched-design-CFS.rst | 20 +++
Documentation/scheduler/sched-feature
From: John Mathew
Add documentation for
-scheduler overview
-scheduler state transtion
-CFS overview
-scheduler data structs
Add rst for scheduler APIs and modify sched/core.c
to add kernel-doc comments.
Suggested-by: Lukas Bulwahn
Co-developed-by: Mostafa Chamanara
Signed-off-by: Mostafa
This adds a hwmon temperature node sensor to the Sparx5 SoC.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
b/arch/arm64/boot/dts/microc
On Thu, May 7, 2020 at 9:55 AM Geert Uytterhoeven
wrote:
> From: Yoshihiro Kaneko
>
> Convert the Renesas Interrupt Controller (INTC) for external pins Device
> Tree binding documentation to json-schema.
>
> Signed-off-by: Yoshihiro Kaneko
> Co-developed-by: Geert Uytterhoeven
> Signed-off-by:
This patch adds a temperature sensor driver to the Sparx5 SoC.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
drivers/hwmon/Kconfig | 10 +++
drivers/hwmon/Makefile | 2 +-
drivers/hwmon/sparx5-temp.c | 154
3 files changed, 165
This add the DT binding specification for the Sparx5 temperature
sensor.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
---
.../bindings/hwmon/microchip,sparx5-temp.yaml | 39 +++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings
This is an add-on series to the main SoC Sparx5 series
(Message-ID: <20200513125532.24585-1-lars.povl...@microchip.com>).
It is expected that the DT patches are to be taken directly by the arm-soc
maintainers.
Lars Povlsen (3):
dt-bindings: hwmon: Add Sparx5 temperature sensor
arm64: dts: spa
opal_xive_donate_page() will reference the newly allocated memory using
__pa(). Since kmemleak is unable to track the physical memory resulting
in false positives, silence those by using kmemleak_ignore().
unreferenced object 0xc000201b53e9 (size 65536):
comm "qemu-kvm", pid 124557, jiffies 4
kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then
pud_populate() and pmd_populate() will use __pa() to reference the newly
allocated memory.
Since kmemleak is unable to track the physical memory resulting in false
positives, silence those by using kmemleak_ignore().
unrefere
On Wed, May 13, 2020 at 02:34:40PM +0200, Oleksij Rempel wrote:
> Add initial cable testing support.
> This PHY needs only 100usec for this test and it is recommended to run it
> before the link is up. For now, provide at least ethtool support, so it
> can be tested by more developers.
>
> This pa
loop_set_status() calls loop_config_discard() to configure discard for
the loop device; however, the discard configuration depends on whether
the loop device uses encryption, and when we call it the encryption
configuration has not been updated yet. Move the call down so we apply
the correct discar
sector_t is now always u64, so we don't need to check for truncation.
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index f1754262fc94..00de7fec0ed5 100
This allows userspace to completely setup a loop device with a single
ioctl, removing the in-between state where the device can be partially
configured - eg the loop device has a backing file associated with it,
but is reading from the wrong offset.
Besides removing the intermediate state, another
LOOP_SET_STATUS(64) will actually allow some lo_flags to be modified; in
particular, LO_FLAGS_AUTOCLEAR can be set and cleared, whereas
LO_FLAGS_PARTSCAN can be set to request a partition scan. Make this
explicit by updating the UAPI to include the flags that can be
set/cleared using this ioctl.
T
This function was now only used by loop_set_capacity(). Just open code
the remaining code in the caller instead.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/block/
In preparation for a new ioctl that needs to copy_from_user(); makes the
code easier to read as well.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/block/loop.c b/driv
This code is used repeatedly.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 00de7fec0ed5..e69ff3c19eff 10
On Fri, May 8, 2020 at 1:58 PM Dietmar Eggemann
wrote:
>
> On 07/05/2020 23:15, Valentin Schneider wrote:
> >
> > On 07/05/20 19:05, John Mathew wrote:
>
> [...]
>
> > It would also be an opportunity to have one place to (at least briefly)
> > describe what the different sched classes do wrt capac
Factor out this code into a separate function, so it can be reused by
other code more easily.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 117 +--
1 file changed, 67 insertions(+), 50 deletions(-)
diff --git a/
This was recently added to block/genhd.c, and takes care of both
updating the capacity and notifying userspace of the new size.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/
On Fri, May 8, 2020 at 1:19 PM Dietmar Eggemann
wrote:
>
> On 07/05/2020 20:05, John Mathew wrote:
>
> [...]
>
> > diff --git a/Documentation/scheduler/cfs-overview.rst
> > b/Documentation/scheduler/cfs-overview.rst
> > new file mode 100644
> > index ..b717f2d3e340
> > --- /dev/null
>
So we can use it without forward declaration. This is a separate commit
to make it easier to verify that this is just a move, without functional
modifications.
Reviewed-by: Christoph Hellwig
Signed-off-by: Martijn Coenen
---
drivers/block/loop.c | 206 +--
This series introduces a new ioctl that makes it possible to atomically
configure a loop device. Previously, if you wanted to set parameters
such as the offset on a loop device, this required calling LOOP_SET_FD
to set the backing file, and then LOOP_SET_STATUS to set the offset.
However, in betwee
figure_loop_size() calculates the loop size based on the passed in
parameters, but at the same time it updates the offset and sizelimit
parameters in the loop device configuration. That is a somewhat
unexpected side effect of a function with this name, and it is only only
needed by one of the two c
On Tue, May 5, 2020 at 5:50 PM Geert Uytterhoeven
wrote:
> Convert the Renesas R-Mobile/R-Car Timer Unit (TMU) Device Tree binding
> documentation to json-schema.
>
> Document missing properties.
> Update the example to match reality.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Rob Herri
Em Tue, May 12, 2020 at 04:59:18PM -0700, Ian Rogers escreveu:
> If allocated, perf_pkg_mask and metric_events need freeing.
Applied, were those found with some tool? Or just by visual inspection?
Also I noticed that evsel->metric_events is correctly initialized to
NULL in evsel__init(), but evse
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is simple and
easy to understand, so the comment descri
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
On 5/13/2020 12:01 AM, Vitaly Kuznetsov wrote:
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs ...
[ 54.106633] smpboot: CPU
struct sg_table is a common structure used for describing a memory
buffer. It consists of a scatterlist with memory pages and DMA addresses
(sgl entry), as well as the number of scatterlist entries: CPU pages
(orig_nents entry) and DMA mapped pages (nents entry).
It turned out that it was a common
On Tue, 12 May 2020 at 19:55, Daniel Thompson
wrote:
>
> On Tue, May 12, 2020 at 02:18:34PM +0530, Sumit Garg wrote:
> > Since commit 42a0bb3f7138 ("printk/nmi: generic solution for safe printk
> > in NMI"), kgdb entry in NMI context defaults to use safe NMI printk()
>
> I didn't see the author on
Balbir Singh writes:
> Subject: [PATCH v6 1/6] arch/x86/kvm: Refactor
arch/x86/kvm: is really not the correct subsystem prefix...
I'll fix it up this time.
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@s
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T
ion_heap_pages_zero() function is not used at all, so remove it to
simplify the ion_heap_sglist_zero() function later.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use common helper for checking the contiguity of the imported dma-buf and
do this check before allocating resources, so the error path is simpler.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://
On Fri, May 8, 2020 at 12:15 AM Valentin Schneider
wrote:
>
>
> On 07/05/20 19:05, John Mathew wrote:
> > Add documentation for
> > -scheduler overview
> > -scheduler state transtion
> > -CFS overview
> > -scheduler data structs
> >
> > Add rst for scheduler APIs and modify sched/core.c
> > to
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that dma_map_sg returns the
numer of the created entries in the DMA address space. However the
subsequent calls to dma_sync_sg_for_{device,cpu} and dma_unmap_sg must be
called with the original number of entries passed to dma_map_sg. The
sg_table->nents in
Balbir Singh writes:
> +With an increasing number of vulnerabilities being reported around data
> +leaks from L1D, a new user space mechanism to flush the L1D cache on
> +context switch is added to the kernel. This should help address
is added to the kernel? This is documentation of an existing f
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
901 - 1000 of 1718 matches
Mail list logo
