On 2020/12/11 3:16, Alex Williamson wrote:
> On Thu, 10 Dec 2020 15:34:19 +0800
> Keqian Zhu wrote:
>
>> Currently we do not clear added dirty bit of bitmap when unwind
>> pin, so if pin failed at halfway, we set unnecessary dirty bit
>> in bitmap. Clearing added dirty bit when unwind pin, use
gt; + dma_mapping_error(dev, dma_addr)
>
> Signed-off-by: Heiner Kallweit
> ---
> If ok, then tbd through which tree this is supposed to go.
> Patch is based on linux-next-20201210.
> ---
[...]
> drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
> drivers/net/wirele
On Wed, 09 Dec 2020 16:00:40 +0800, Yong Wu wrote:
> Only rename the header guard for all the SoC larb port header file.
> No funtional change.
>
> Suggested-by: Krzysztof Kozlowski
> Signed-off-by: Yong Wu
> ---
> include/dt-bindings/memory/mt2701-larb-port.h | 4 ++--
> include/dt-bindings/me
On Wed, 9 Dec 2020 09:44:44 +0800
Lu Baolu wrote:
> Add the API for getting the domain from a vfio group. This could be used
> by the physical device drivers which rely on the vfio/mdev framework for
> mediated device user level access. The typical use case like below:
>
> unsigned int pa
On Thu, Dec 10, 2020 at 03:47:50PM +0100, Heiner Kallweit wrote:
> Zillions of drivers use the unlikely() hint when checking the result of
> dma_mapping_error(). This is an inline function anyway, so we can move
> the hint into the function and remove it from drivers.
> From time to time discussion
On Thu, 10 Dec 2020 15:34:19 +0800
Keqian Zhu wrote:
> Currently we do not clear added dirty bit of bitmap when unwind
> pin, so if pin failed at halfway, we set unnecessary dirty bit
> in bitmap. Clearing added dirty bit when unwind pin, userspace
> will see less dirty page, which can save much
Suravee Suthikulpanit @ 2020-12-10 09:24 MST:
> Currently, macros related to the interrupt remapping table length are
> defined separately. This has resulted in an oversight in which one of
> the macros were missed when changing the length. To prevent this,
> redefine the macros to add built-in
On 2020-12-09 9:04 p.m., Dan Williams wrote:
> On Wed, Dec 9, 2020 at 6:07 PM Logan Gunthorpe wrote:
>>
>>
>>
>> On 2020-12-09 6:22 p.m., Dan Williams wrote:
>>> On Mon, Nov 9, 2020 at 8:47 AM Logan Gunthorpe wrote:
On 2020-11-09 2:12 a.m., Christoph Hellwig wrote:
> On
On Thu, Dec 10, 2020 at 03:36:36PM +, Deucher, Alexander wrote:
> [AMD Public Use]
>
> > -Original Message-
> > From: Merger, Edgar [AUTOSOL/MAS/AUGS]
> > Sent: Thursday, December 10, 2020 5:48 AM
> > To: Deucher, Alexander ; Huang, Ray
> > ; Kuehling, Felix
> > Cc: Will Deacon ; li
Currently, macros related to the interrupt remapping table length are
defined separately. This has resulted in an oversight in which one of
the macros were missed when changing the length. To prevent this,
redefine the macros to add built-in sanity check.
Also, rename macros to use the name of the
[AMD Public Use]
> -Original Message-
> From: Merger, Edgar [AUTOSOL/MAS/AUGS]
> Sent: Thursday, December 10, 2020 5:48 AM
> To: Deucher, Alexander ; Huang, Ray
> ; Kuehling, Felix
> Cc: Will Deacon ; linux-ker...@vger.kernel.org;
> linux- p...@vger.kernel.org; iommu@lists.linux-founda
gh which tree this is supposed to go.
Patch is based on linux-next-20201210.
---
drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 +--
drivers/crypto/hisilicon/hpre/hpre_crypto.c | 2 +-
.../marvell/octeontx/otx_cptvf_reqmgr.c | 5 ++--
drivers/crypto/mediatek/mtk-aes.c
Hi All,
On 12/10/20 1:50 AM, Will Deacon wrote:
On Wed, Dec 09, 2020 at 10:07:46AM -0800, Linus Torvalds wrote:
On Wed, Dec 9, 2020 at 6:12 AM Will Deacon wrote:
Please pull this one-liner AMD IOMMU fix for 5.10. It's actually a fix
for a fix, where the size of the interrupt remapping table
Alright. Done that.
This should be it finally I believe.
Which will be the initial kernel-version that incorporates that?
-Original Message-
From: Deucher, Alexander
Sent: Mittwoch, 9. Dezember 2020 15:24
To: Merger, Edgar [AUTOSOL/MAS/AUGS] ; Huang, Ray
; Kuehling, Felix
Cc: Will Dea
On 19/11/2020 12:11, Shameer Kolothum wrote:
RFC v1 --> v2:
- Added a generic interface for IOMMU drivers to retrieve all the
RMR info associated with a given IOMMU.
- SMMUv3 driver gets the RMR list during probe() and installs
bypass STEs for all the SIDs in the RMR list. This is to
On Wed, Dec 09, 2020 at 04:34:30AM -0800, tangzhenhao wrote:
> At line 362 in drivers/iommu/fsl_pamu_domain.c, the ret-val of
> kmem_cache_zalloc should be checked to avoid null-ptr-deref bug.
>
> Signed-off-by: tangzhenhao
> ---
> drivers/iommu/fsl_pamu_domain.c | 4
> 1 file changed,
On Sun, Dec 06, 2020 at 01:43:51AM -0800, tangzhenhao wrote:
> At line 600 in drivers/iommu/msm_iommu.c, the ret-val of kzalloc should be
> checked to avoid null-ptr-deref bug.
There's no need to mention the line number of the file name in the commit
message -- that information is already availab
17 matches
Mail list logo
