On Wed, Aug 05, 2020 at 09:44:36AM -0400, Michael S. Tsirkin wrote:
> Virtio input is modern-only. Use LE accessors for config space.
>
> Signed-off-by: Michael S. Tsirkin
Reviewed-by: Gerd Hoffmann
Hi Alessio,
Thank you for working on this, I'm excited to see things moving again on
this front!
What I would really like to see in the long-term is the ability for FUSE
to support passthrough for specific areas of a file, i.e. the ability to
specify different passthrough fds for different
' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Raul-E-Rangel/mmc-sdhci-acpi-Fix-HS400-tuning-for-AMDI0040/20200819-063255
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
18445bf405cb331117bc98427b1ba6f12418ad17
config
On 8/18/20 6:12 PM, Udip Pant wrote:
While using dynamic program extension (of type BPF_PROG_TYPE_EXT), we
need to check the program type of the target program to grant the read /
write access to the packet data.
The BPF_PROG_TYPE_EXT type can be used to extend types such as XDP, SKB
and
The couple of #includes are unused by now; remove to prevent namespace
pollution.
This fixes e.g. build of dm_thin, which has a VIRTUAL symbol that
conflicted with the newly-introduced one in mach-loongson64/boot_param.h.
Fixes: 39c1485c8baa ("MIPS: KVM: Add kvm guest support for Loongson-3")
On Tue, Aug 18, 2020 at 11:57:39AM -0700, Guenter Roeck wrote:
> On Mon, Aug 17, 2020 at 05:09:13PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.8.2 release.
> > There are 464 patches in this series, all will be posted as a response
> > to this one.
On Tue, Aug 18, 2020 at 04:35:23PM -0600, Shuah Khan wrote:
> On 8/17/20 9:09 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.8.2 release.
> > There are 464 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues
On 19.08.2020 00:44, Chris Packham wrote:
> Hi Again,
>
> On 17/08/20 9:09 am, Chris Packham wrote:
>
>>
>> On 14/08/20 6:19 pm, Heiner Kallweit wrote:
>>> On 14.08.2020 04:48, Chris Packham wrote:
Hi,
I'm seeing a problem with accessing spi-nor after upgrading a T2081
based
I no longer have the setup for testing. The changes look good to me.
Reviewed-by: Vijai Kumar K
Thanks,
Vijai Kumar K
On Mon, Aug 17, 2020 at 12:30 PM Krzysztof Kozlowski wrote:
>
> Hi,
>
> Changes since v1:
> 1. Mutex unlock fix in patch 8/13.
>
> Best regards,
> Krzysztof
On 18. 08. 20, 12:47, Tony Lindgren wrote:
> * Jiri Slaby [200818 10:14]:
>> On 18. 08. 20, 11:56, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Jiri Slaby [200818 08:24]:
On 17. 08. 20, 15:54, Tony Lindgren wrote:
> If write returns zero we currently end up removing the message
> from the
Stephen Rothwell writes:
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
> drivers/net/wireless/ath/ath11k/dp_rx.c
>
> between commit:
>
> 58e813cceabd ("treewide: Use fallthrough pseudo-keyword")
>
> from the kspp-gustavo tree and commit:
>
>
On 8/18/20 10:57 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200818:
>
Is this some kind of mis-merge?
In sas_discover.c:
case SAS_SATA_DEV:
case SAS_SATA_PM:
#ifdef CONFIG_SCSI_SAS_ATA
error = sas_discover_sata(dev);
break;
#else
Hi,
* Drew Fustini [200722 12:09]:
> Change the handling of pin config flags from if/else to switch
> statement to make the code more readable and cleaner.
>
> Suggested-by: Gustavo A. R. Silva
> Signed-off-by: Drew Fustini
This looks OK to me:
Acked-by: Tony Lindgren
I've lost track of
On Tue, Aug 18, 2020 at 12:27:58PM -0700, Badhri Jagan Sridharan wrote:
> "tReceiverResponse 15 ms Section 6.6.2
> The receiver of a Message requiring a response Shall respond
> within tReceiverResponse in order to ensure that the
> sender’s SenderResponseTimer does not expire."
>
> When the cpu
On Mon, Aug 17, 2020 at 11:38:27AM -0700, Badhri Jagan Sridharan wrote:
> The patch addresses the compliance test failures while running
> TD.PD.CP.E3, TD.PD.CP.E4, TD.PD.CP.E5 of the "Deterministic PD
> Compliance MOI" test plan published in https://www.usb.org/usbc.
> For a product to be Type-C
syzbot has found a reproducer for the following issue on:
HEAD commit:ce8056d1 wip: changed copy_from_user where instrumented
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=12a834ee90
kernel config:
On Tue 18-08-20 16:18:56, Andrew Morton wrote:
> On Tue, 18 Aug 2020 07:50:28 -0700 syzbot
> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:a1d21081 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
> > git tree: upstream
> > console output:
Name extraction in exfat_find_dir_entry() also doesn't care NameLength,
so the name may be incorrect.
Replace the name extraction in exfat_find_dir_entry() with using
exfat_entry_set_cache and exfat_get_uniname_from_name_entries(),
like exfat_readdir().
And, remove unused functions/parameters.
**
The current implementation doesn't care NameLength when extracting
the name from Name dir-entries, so the name may be incorrect.
(Without null-termination, Insufficient Name dir-entries, etc)
Add a NameLength check when extracting the name from Name dir-entries
to extract correct name.
And, change
On Tue, 18 Aug 2020 18:54:44 +0200,
Mike Pozulp wrote:
>
> The Galaxy Book Ion uses the same ALC298 codec as other Samsung laptops
> which have the no headphone sound bug, like my Samsung Notebook. The
> Galaxy Book owner confirmed that this patch fixes the bug.
>
> BugLink:
* Jiri Slaby [200819 06:20]:
> On 18. 08. 20, 12:47, Tony Lindgren wrote:
> > * Jiri Slaby [200818 10:14]:
> >> On 18. 08. 20, 11:56, Tony Lindgren wrote:
> >>> Hi,
> >>>
> >>> * Jiri Slaby [200818 08:24]:
> On 17. 08. 20, 15:54, Tony Lindgren wrote:
> > If write returns zero we
Fix linkage error when CONFIG_BINFMT_ELF is selected but CONFIG_COREDUMP
is not:
ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function
`elf_core_write_extra_phdrs':
elfcore.c:(.text+0x172): undefined reference to `dump_emit'
ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function
-20200818
i386 randconfig-a015-20200818
i386 randconfig-a011-20200818
i386 randconfig-a013-20200818
i386 randconfig-a012-20200818
i386 randconfig-a014-20200818
x86_64 randconfig-a006-20200819
x86_64
Hello,
syzbot found the following issue on:
HEAD commit:4993e4fe Add linux-next specific files for 20200814
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=107ad7d690
kernel config: https://syzkaller.appspot.com/x/.config?x=2055bd0d83d5ee16
dashboard
TIF_SLD can only be set if a user space thread hits split lock and
sld_state == sld_warn. This flag is set to indicate SLD (split lock
detection) is turned off for the thread, so rename it to
TIF_SLD_DISABLED, which is pretty self explaining.
Suggested-by: Sean Christopherson
Suggested-by:
On Tue, Aug 18, 2020 at 07:30:33PM +0300, Jarkko Sakkinen wrote:
> On Tue, Aug 18, 2020 at 02:51:41PM +0300, Mike Rapoport wrote:
> > On Tue, Aug 18, 2020 at 08:30:29AM +0300, Jarkko Sakkinen wrote:
> > > On Sun, Jul 26, 2020 at 11:14:08AM +0300, Mike Rapoport wrote:
> > > > >
> > > > > I'm not
Introduce split_lock_virt_switch(), which is used for toggling split
lock detection setting as well as updating TIF_SLD_DISABLED flag to make
them consistent. Note, it can only be used in sld warn mode, i.e.,
X86_FEATURE_SPLIT_LOCK_DETECT && !X86_FEATURE_SLD_FATAL.
The FATAL check is handled by
Introduce a synthetic feature flag X86_FEATURE_SLD_FATAL, which means
kernel is in sld_fatal mode if set.
Now sld_state is not needed any more that the state of SLD can be
inferred from X86_FEATURE_SPLIT_LOCK_DETECT and X86_FEATURE_SLD_FATAL.
Suggested-by: Sean Christopherson
Signed-off-by:
Hi maintainers,
Please help review this new version and give comments. There is only one
minor change from previous v9, i.e., adding patch 8.
---
This series aims to add the virtualization of split lock detection in
KVM.
Due to the fact that split lock detection is tightly coupled with CPU
It should be more resonable to set cpu_model_supports_sld to true after
BSP is verified to have feature split lock detection.
It also avoids externing the cpu_model_supports_sld when enumerate the
split lock detection in a guest via PV interface in a future patch.
Signed-off-by: Xiaoyao Li
---
Introduce KVM_FEATURE_SPLIT_LOCK_DETECT, with which guests running
on KVM can enumerate the avaliablility of feature split lock detection.
Introduce KVM_HINTS_SLD_FATAL, which tells whether host is sld_fatal mode,
i.e., whether split lock detection is forced on for guest vcpu.
Signed-off-by:
Le 19/08/2020 à 06:00, Ran Wang a écrit :
From: Peng Ma
This patch enables ACPI support in RCPM driver.
Can you change the subject to "soc: fsl: enable acpi support in RCPM
driver" ?
Signed-off-by: Peng Ma
Signed-off-by: Ran Wang
---
Change in v3:
- Add #ifdef CONFIG_ACPI for
TEST_CTRL MSR is per-core scope, i.e., the sibling threads in the same
physical core share the same MSR. This requires additional constraint
when exposing it to guest.
1) When host SLD state is sld_off (no X86_FEATURE_SPLIT_LOCK_DETECT),
feature split lock detection is unsupported/disabled.
When running as guest, enumerating feature split lock detection through
CPU model is not easy since CPU model is configurable by host VMM.
If running upon KVM, it can be enumerated through
KVM_FEATURE_SPLIT_LOCK_DETECT, and if KVM_HINTS_SLD_FATAL is set, it
needs to be set to sld_fatal mode.
Unconditionally allow the guest to read and zero-write MSR TEST_CTRL.
This matches the fact that most Intel CPUs support MSR TEST_CTRL, and
it also alleviates the effort to handle wrmsr/rdmsr when split lock
detection is exposed to the guest in a future patch.
Signed-off-by: Xiaoyao Li
---
The bogus case can never happen, i.e., when sld_state == sld_off, guest
won't trigger split lock #AC and of course no handle_guest_split_lock()
will be called.
Besides, drop bogus case also makes future patch easier to remove
sld_state if we reach the alignment that it must be sld_warn or
Hi Christophe
On Wednesday, August 19, 2020 2:48 PM, Christophe Leroy wrote:
>
>
>
> Le 19/08/2020 à 06:00, Ran Wang a écrit :
> > From: Peng Ma
> >
> > This patch enables ACPI support in RCPM driver.
>
> Can you change the subject to "soc: fsl: enable acpi support in RCPM driver" ?
Sure.
Stephen Rothwell writes:
> Hi all,
>
> In commit
>
> 3b9fb6791e71 ("wcn36xx: Fix reported 802.11n rx_highest rate
> wcn3660/wcn3680")
>
> Fixes tag
>
> Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680
>
> has these problem(s):
>
> - Subject has leading but no
Please remove the settings->size check. The driver sometimes just
writes a modified version of the read settings data. This would fail if
stored size is invalid. This value of size is not solely in my hands, I
can't guarantee Windows driver does a sanity check, also cases of flash
data corruption
On Fri, Aug 14, 2020 at 5:03 PM Zhaoyang Huang wrote:
>
> Some system(like android) will turbo read during startup via expanding the
> readahead window and then set it back to normal(128kb as usual). However, some
> files in the system process context will keep to be opened since it is opened
>
Hi all,
this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs
with a separate new dma_alloc_pages API, which is available on all
platforms. In addition to cleaning up the convoluted code path, this
ensures that other drivers that have asked for better support for
non-coherent
The au1000-eth driver contains none of the manual cache synchronization
required for using DMA_ATTR_NON_CONSISTENT. From what I can tell it
can be used on both dma coherent and non-coherent DMA platforms, but
I suspect it has been buggy on the non-coherent platforms all along.
Signed-off-by:
This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare
for untangling the coherent vs non-coherent DMA allocation API.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/i825xx/lasi_82596.c | 24 ++--
drivers/net/ethernet/i825xx/lib82596.c | 36
Just merge these helpers into the main dma_direct_{alloc,free} routines,
as the additional checks are always false for the two callers.
Signed-off-by: Christoph Hellwig
---
arch/x86/kernel/amd_gart_64.c | 6 +++---
include/linux/dma-direct.h| 4
kernel/dma/direct.c | 39
dma_declare_coherent_memory should not be in a DMA API guide aimed
at driver writers (that is consumers of the API). Move it to a comment
near the function instead.
Signed-off-by: Christoph Hellwig
---
Documentation/core-api/dma-api.rst | 24
kernel/dma/coherent.c
Signed-off-by: Christoph Hellwig
---
arch/mips/include/asm/jazzdma.h | 2 -
arch/mips/jazz/jazzdma.c| 70 -
2 files changed, 72 deletions(-)
diff --git a/arch/mips/include/asm/jazzdma.h b/arch/mips/include/asm/jazzdma.h
index
All users are gone now, remove the API.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 1 -
arch/mips/jazz/jazzdma.c| 1 -
arch/mips/mm/dma-noncoherent.c | 6 --
arch/parisc/Kconfig | 1 -
arch/parisc/kernel/pci-dma.c| 6 --
Use the proper modern API to transfer cache ownership for incoherent DMA.
Note that this moves the DMA helpers to the main lib82596.c file, so
that they can use virt_to_dma.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/i825xx/lasi_82596.c | 11 +--
Use the proper modern API to transfer cache ownership for incoherent DMA.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/53c700.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/53c700.c b/drivers/scsi/53c700.c
index 521950d0731e4a..57a08c42d00325
Switch from coherent DMA pools to those backed by dma_alloc_pages. This
helps device with non-coherent DMA to avoid host accesses to uncached
memory for every submission of a larger than single entry I/O.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/pci.c | 80
On Tue, Aug 18, 2020 at 12:55:59PM -0300, Daniel Gutson wrote:
> > If you care about other (malicious) code writing to the driver, please
> > explain
> > what the specific attack scenario is that you are worried about, and
> > why you think
> > this is not sufficient. What code would be able to
Use the proper modern API to transfer cache ownership for incoherent DMA.
This also means we can allocate the buffer memory with the proper
direction instead of bidirectional.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 44
1 file
All operations are based on the controller, not the host page size.
Switch the dma pool to use the controller page size as well to avoid
massive overallocations on large page size systems.
Signed-off-by: Christoph Hellwig
---
drivers/nvme/host/pci.c | 3 ++-
1 file changed, 2 insertions(+), 1
Use the proper modern API to transfer cache ownership for incoherent DMA.
This also means we can allocate the memory as DMA_TO_DEVICE instead
of bidirectional.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sgiwd93.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Peng Ma
This patch enables ACPI support in RCPM driver.
Signed-off-by: Peng Ma
Signed-off-by: Ran Wang
---
Change in v4:
- Make commit subject more accurate
- Remove unrelated new blank line
Change in v3:
- Add #ifdef CONFIG_ACPI for acpi_device_id
- Rename rcpm_acpi_imx_ids to
Add an new variant of a dmapool that uses non-coherent memory from
dma_alloc_pages. Unlike the existing mempool_create this one
initialized a pool allocated by the caller to avoid a pointless extra
allocation. At some point it might be worth to also switch the coherent
allocation over to a
Use the proper modern API to transfer cache ownership for incoherent DMA.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/seeq/sgiseeq.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/seeq/sgiseeq.c
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'mwifiex_pcie_alloc_buffers()' (see details in
the
Add a new API to allocate and free pages that are guaranteed to be
addressable by a device, but otherwise behave like pages allocated by
alloc_pages. The intended APIs to sync them for use with the device
and cpu are dma_sync_single_for_{device,cpu} that are also used for
streaming mappings.
There is no harm in just always clearing the SME encryption bit, while
significantly simplifying the interface.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-direct.h | 2 +-
arch/mips/bmips/dma.c | 2 +-
arch/mips/cavium-octeon/dma-octeon.c | 2 +-
Add a new file that contains helpera for misc DMA ops, which is only
built when CONFIG_DMA_OPS is set.
Signed-off-by: Christoph Hellwig
---
kernel/dma/Makefile | 1 +
kernel/dma/mapping.c | 47 +---
kernel/dma/ops_helpers.c | 51
The __phys_to_dma vs phys_to_dma distinction isn't exactly obvious. Try
to improve the situation by renaming __phys_to_dma to
phys_to_dma_unencryped, and not forcing architectures that want to
override phys_to_dma to actually provide __phys_to_dma.
Signed-off-by: Christoph Hellwig
---
Replace the currently open code copy.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 01120510968fa1..2e280b9c063449 100644
--- a/kernel/dma/direct.c
+++
Add back a hook to optimize dcache flushing after reading executable
code using DMA. This gets ia64 out of the business of pretending to
be dma incoherent just for this optimization.
Signed-off-by: Christoph Hellwig
---
arch/ia64/Kconfig | 3 +--
arch/ia64/kernel/dma-mapping.c
When transferring DMA ownership back to the CPU there should never
be any writeback from the cache, as the buffer was owned by the
device until now. Instead it should just be invalidated for the
mapping directions where the device could have written data.
Note that the changes rely on the fact
On Wed, Aug 19, 2020 at 02:57:14PM +0800, Hsin-Yi Wang wrote:
> I think you missed this email :)
>
> -- Forwarded message -
> From: Sam Ravnborg
> Date: Tue, Aug 11, 2020 at 4:35 AM
> Subject: Re: [PATCH v14 0/2] Add initial support for slimport anx7625
> To: Xin Ji
> Cc: ,
Move the detailed gfp_t setup from __dma_direct_alloc_pages into the
caller to clean things up a little.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index
Greetings from Mrs Elodie Antoine,
Calvary Greetings in the name of the LORD Almighty and Our LORD JESUS CHRIST
the giver of every good thing. Good day,i know this letter will definitely come
to you as a huge surprise, but I implore you to take the time to go through it
carefully as the
Switch the 53c700 driver to only use non-coherent descriptor memory if it
really has to because dma_alloc_coherent fails. This doesn't matter for
any of the platforms it runs on currently, but that will change soon.
To help with this two new helpers to transfer ownership to and from the
device
The jazzdma ops implement support for a very basic IOMMU. Thus we really
should not use the dma-direct code that takes physical address limits
into account. This survived through the great MIPS DMA ops cleanup mostly
because I was lazy, but now it is time to fully split the implementations.
DMA_ATTR_NON_CONSISTENT is a no-op except on PARISC and some mips
configs, so don't set it in this ARM specific driver.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
DMA_ATTR_NON_CONSISTENT is a no-op except on PARISC and some mips
configs, so don't set it in this ARM specific driver part.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
On Tue, Aug 18, 2020 at 05:35:04PM -0700, Scott Branden wrote:
>
>
> On 2020-08-18 10:44 a.m., Greg Kroah-Hartman wrote:
> > On Tue, Aug 18, 2020 at 10:23:42AM -0700, Scott Branden wrote:
> >> Hi Greg,
> >>
> >> On 2020-08-18 6:53 a.m., Greg Kroah-Hartman wrote:
> >>> On Wed, Aug 05, 2020 at
The V4L2-FLAG-MEMORY-NON-CONSISTENT flag is entirely unused, and causes
weird gymanstics with the DMA_ATTR_NON_CONSISTENT flag, which is
unimplemented except on PARISC and some MIPS configs, and about to be
removed.
Signed-off-by: Christoph Hellwig
---
.../userspace-api/media/v4l/buffer.rst
On 2020-08-18 17:56:49 [-0700], Guenter Roeck wrote:
> Nice catch. FWIW, there is no obvious reason why this would need to be atomic.
> The calling code does not set a lock, meaning there can be two (or more)
> callers entering this code. Weird, especially since the code looks like it
> would
On 18. 08. 20, 13:43, Greg KH wrote:
> On Tue, Aug 18, 2020 at 10:56:52AM +0200, Jiri Slaby wrote:
>> That is:
>> 1) call the parameter 'xy' to denote what it really is, not generic 'p'
>> 2) tell the compiler and users that we expect an array:
>>* with at least 2 chars (static 2)
>>*
To prevent a compiler error when a method call alloc_pages is
added (which I plan to for the dma_map_ops).
Signed-off-by: Christoph Hellwig
---
include/linux/gfp.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index
On 2020-08-12 14:45:22 [+0200], Thomas Graziadei wrote:
> Hi Sebastian,
Hi Thomas,
> any progress on your side?
due to lack of time none. But I am on it…
> Do you think the patch could be applied for the next versions?
So I had a theory why it happens but then you said no so now I need
to
Starting with core version 4.3.a the DMA bus attributes can (and should) be
read from the INTERFACE_DESCRIPTION (0x10) register.
For older core versions, this will still need to be provided from the
device-tree.
The bus-type values are identical to the ones stored in the device-trees,
so we just
The clock may also be required to read registers from the IP core (if it is
provided and the driver needs to control it).
So, move it earlier in the probe.
Signed-off-by: Alexandru Ardelean
---
drivers/dma/dma-axi-dmac.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
The channel parameters (which are read from the device-tree) are adjusted
for the DMAEngine framework in the axi_dmac_parse_chan_dt() function, after
they are read from the device-tree.
When we want to read these from registers, we will need to use the same
logic, so this change splits the logic
All these attributes will be read from registers in newer core versions, so
just wrap the logic into a function.
Signed-off-by: Alexandru Ardelean
---
drivers/dma/dma-axi-dmac.c | 39 --
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git
The 'version' of the IP core will be needed to adapt the driver to a new
feature (i.e. reading some DMA parameters from registers).
To do that, the version will be checked, so this is being moved out of the
axi_dmac_detect_caps() function.
Signed-off-by: Alexandru Ardelean
---
Hi
Am 18.08.20 um 22:28 schrieb Randy Dunlap:
> From: Randy Dunlap
>
> sparse complains about having 2 "__iomem" attributes on the same line
> where only one is needed since the first one applies to everything
> up to the ending ';'.
> However, to make it clear(er) that both of these pointers
Le 18/08/2020 à 20:23, Christophe Leroy a écrit :
Le 18/08/2020 à 20:05, Christoph Hellwig a écrit :
On Tue, Aug 18, 2020 at 07:46:22PM +0200, Christophe Leroy wrote:
I gave it a go on my powerpc mpc832x. I tested it on top of my newest
series that reworks the 32 bits signal handlers (see
Converting the Makefile to use the new tools buildsystem.
Signed-off-by: Heikki Krogerus
---
tools/usb/Build| 2 ++
tools/usb/Makefile | 53 +++---
2 files changed, 47 insertions(+), 8 deletions(-)
create mode 100644 tools/usb/Build
diff --git
The error message if 'pci_set_consistent_dma_mask()' fails is misleading.
The function call uses 32 bits, but the error message reports 64.
Moreover, according to the comment above 'dma_set_mask_and_coherent()'
definition, such an error can never happen.
So, simplify code, axe the misleading
* Alexander A. Klimov [200719 11:48]:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
Thanks applying into omap-for-v5.10/soc.
Tony
* Alexander A. Klimov [200719 11:59]:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
Thanks applying into omap-for-v5.10/soc.
Tony
* Alexander A. Klimov [200719 12:09]:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
Thanks applying into omap-for-v5.10/soc.
Tony
* Alexander A. Klimov [200719 12:27]:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
Thanks applying into omap-for-v5.10/soc.
Tony
* Alexander A. Klimov [200719 13:30]:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
Thanks applying into omap-for-v5.10/soc.
Tony
On 18.08.2020 14:47, Roger Pau Monné wrote:
> On Tue, Aug 18, 2020 at 02:01:35PM +0200, Marek Marczykowski-Górecki wrote:
>> On Mon, Aug 17, 2020 at 11:00:13AM +0200, Roger Pau Monné wrote:
>>> On Sun, Aug 16, 2020 at 02:19:49AM +0200, Marek Marczykowski-Górecki wrote:
In case of Xen PV dom0,
On Tue, Aug 18, 2020 at 06:25:42PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 18, 2020 at 12:51:10PM +0200, Peter Zijlstra wrote:
> > Convert the performance sensitive users of
> > smp_call_single_function_async() over to the new
> > irq_work_queue_remote_static().
> >
> > The new API is
On Wed, Aug 19, 2020 at 09:16:59AM +0200, Christophe Leroy wrote:
> I made a test with only the first patch of your series: That's definitely
> the culprit. With only that patch applies, the duration is 6.64 seconds,
> that's a 25% degradation.
For the record: the first patch is:
mem:
* Randy Dunlap [200726 03:22]:
> Drop the repeated word "is".
Thanks applying into omap-for-v5.9/omap1.
Tony
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/rsi/rsi_91x_core.c:23: warning: Incorrect use of
kernel-doc format: * rsi_determine_min_weight_queue() - This function
determines the queue with
drivers/net/wireless/rsi/rsi_91x_core.c:30: warning: Function parameter or
There are only 2 kernel-doc headers in this file and both are
incorrect. The first one does not attempt to document the function at
all and the second one is suffering from severe doc-rot; the format is
wrong and only 1 out of 3 parameters are being documented.
Fixes the following W=1 kernel
'freq_list' is used in some source files which include hostap.h, but
not all. The compiler complains about the times it's not used. Mark
it as __maybe_used to tell the compiler that this is not only okay,
it's expected.
Fixes the following W=1 kernel build warning(s):
In file included from
Firstly a rename, then a split (there are 2 'len's that need documenting).
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/ti/wlcore/cmd.c:832: warning: Function parameter or
member 'buf_len' not described in 'wl1271_cmd_test'
drivers/net/wireless/ti/wlcore/cmd.c:832:
1 - 100 of 1581 matches
Mail list logo
