Fixes: 0b741b8234c8 ("soc: bcm: brcmstb: Add support for S2/S3/S5 suspend states
(ARM)")
Cc: Brian Norris
Cc: Doug Berger
Cc: Florian Fainelli
Cc: Justin Chen
Cc: Lee Jones
Cc: Markus Mayer
Signed-off-by: Guilherme G. Piccoli
Acked-by: Florian Fainelli
Likewise, I am not sure if
of a panic notifiers refactor - this notifier in
the future will be moved to a new list, that encompass the
information notifiers only.
Fixes: 9eb60880d9a9 ("bus: brcmstb_gisb: add notifier handling")
Cc: Brian Norris
Cc: Florian Fainelli
Signed-off-by: Guilherme G. Piccoli
Acked-by: Fl
On 10/25/2021 6:02 PM, Guenter Roeck wrote:
On 10/25/21 4:55 PM, Dmitry Osipenko wrote:
26.10.2021 02:29, Florian Fainelli пишет:
On 6/4/21 7:03 AM, Lee Jones wrote:
This is a rebase/refresh of a set sent out, reviewed,
then forgotten about. It's still considered useful.
Here
On 6/4/21 7:03 AM, Lee Jones wrote:
> This is a rebase/refresh of a set sent out, reviewed,
> then forgotten about. It's still considered useful.
>
> Here is an excerpt from the previous attempt:
>
> "Hi Russell, ARM SoC maintainers,
>
> here's the full set of patches that remove arm_pm_resta
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Split the debugfs creation to make the code reusable for supporting
> different bounce buffer pools, e.g. restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Update is_swiotlb_active to add a struct device argument. This will be
> useful later to allow for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Update is_swiotlb_buffer to add a struct device argument. This will be
> useful later to allow for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct.
> The restricted DMA pool is preferred if available.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool.
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new wrapper __dma_direct_free_pages() that will be useful later
> for swiotlb_free().
>
> Signed-off-by: Claire Chang
Reviewed-by: Florian Fainelli
--
Florian
(!mem)
> + return -ENOMEM;
> +
> + if (PageHighMem(pfn_to_page(PHYS_PFN(rmem->base {
> + kfree(mem);
> + return -EINVAL;
This could probably deserve a warning here to indicate that the reserved
area must be accessible within the linear mapping as I would expect a
lot of people to trip over that.
Reviewed-by: Florian Fainelli
--
Florian
On 5/17/2021 11:42 PM, Claire Chang wrote:
> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
> initialization to make the code reusable.
>
> Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl.
>
> Signed-off-by: Claire Chang
> ---
> kernel/dma/swi
On 5/10/2021 11:15 AM, Julien Grall wrote:
> Hi Christoph,
>
> On 10/05/2021 09:40, Christoph Hellwig wrote:
>> On Sat, May 08, 2021 at 12:32:37AM +0100, Julien Grall wrote:
>>> The pointer dereferenced seems to suggest that the swiotlb hasn't been
>>> allocated. From what I can tell, this may
On 3/10/2021 1:40 PM, Rob Herring wrote:
> On Wed, Mar 10, 2021 at 9:08 AM Will Deacon wrote:
>>
>> Hi Claire,
>>
>> On Tue, Feb 09, 2021 at 02:21:30PM +0800, Claire Chang wrote:
>>> Introduce the new compatible string, restricted-dma-pool, for restricted
>>> DMA. One can specify the address an
On 1/14/21 1:08 AM, Claire Chang wrote:
> On Wed, Jan 13, 2021 at 7:48 AM Florian Fainelli wrote:
>>
>> On 1/5/21 7:41 PM, Claire Chang wrote:
>>> If a device is not behind an IOMMU, we look up the device node and set
>>> up the restricted DMA when the
On 1/13/21 7:27 AM, Robin Murphy wrote:
> On 2021-01-13 13:59, Nicolas Saenz Julienne wrote:
>> Hi All,
>>
>> On Tue, 2021-01-12 at 16:03 -0800, Florian Fainelli wrote:
>>> On 1/5/21 7:41 PM, Claire Chang wrote:
>>>> Add the initialization function to crea
On 1/12/2021 8:25 PM, Tomasz Figa wrote:
> On Wed, Jan 13, 2021 at 12:56 PM Florian Fainelli
> wrote:
>>
>>
>>
>> On 1/12/2021 6:29 PM, Tomasz Figa wrote:
>>> Hi Florian,
>>>
>>> On Wed, Jan 13, 2021 at 3:01 AM Florian Fainelli
>
On 1/12/2021 6:29 PM, Tomasz Figa wrote:
> Hi Florian,
>
> On Wed, Jan 13, 2021 at 3:01 AM Florian Fainelli wrote:
>>
>> On 1/11/21 11:48 PM, Claire Chang wrote:
>>> On Fri, Jan 8, 2021 at 1:59 AM Florian Fainelli
>>> wrote:
>>>>
>>
On 1/5/21 7:41 PM, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes in the device tree.
>
> Signed-off-by: Claire Chang
> ---
> include/linux/device.h | 4 ++
> include/linux/swiotlb.h | 7 +-
> kernel/dma/Kconfig
On 1/7/21 1:19 PM, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 07, 2021 at 10:09:14AM -0800, Florian Fainelli wrote:
>> On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
>>> On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
>>>> Hi Greg and Konrad,
>>&
On 1/5/21 7:41 PM, Claire Chang wrote:
> If a device is not behind an IOMMU, we look up the device node and set
> up the restricted DMA when the restricted-dma-pool is presented.
>
> Signed-off-by: Claire Chang
> ---
[snip]
> +int of_dma_set_restricted_buffer(struct device *dev)
> +{
> + st
On 1/5/21 7:41 PM, Claire Chang wrote:
> Add the functions, swiotlb_alloc and swiotlb_free to support the
> memory allocation from restricted DMA pool.
>
> Signed-off-by: Claire Chang
> ---
[snip]
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 30ccbc08e229..126e9b3354d6 100644
On 1/5/21 7:41 PM, Claire Chang wrote:
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools provide a basic level of protection against
> the DMA overwriting buffer contents at unexpected times. However, to
> protect against general dat
On 1/11/21 11:48 PM, Claire Chang wrote:
> On Fri, Jan 8, 2021 at 1:59 AM Florian Fainelli wrote:
>>
>> On 1/7/21 9:42 AM, Claire Chang wrote:
>>
>>>> Can you explain how ATF gets involved and to what extent it does help,
>>>> besides enforcing a secur
On 1/7/21 10:00 AM, Konrad Rzeszutek Wilk wrote:
>>>
>>>
>>> - Nothing stops the physical device from bypassing the SWIOTLB buffer.
>>>That is if an errant device screwed up the length or DMA address, the
>>>SWIOTLB would gladly do what the device told it do?
>>
>> So the system needs to p
On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote:
> On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote:
>> Hi Greg and Konrad,
>>
>> This change is intended to be non-arch specific. Any arch that lacks DMA
>> access
>> control and has devices not behind an IOMMU can make use of it. Could y
On 1/7/21 9:42 AM, Claire Chang wrote:
>> Can you explain how ATF gets involved and to what extent it does help,
>> besides enforcing a secure region from the ARM CPU's perpsective? Does
>> the PCIe root complex not have an IOMMU but can somehow be denied access
>> to a region that is marked NS=0
Hi,
First of all let me say that I am glad that someone is working on a
upstream solution for this issue, would appreciate if you could CC and
Jim Quinlan on subsequent submissions.
On 1/5/21 7:41 PM, Claire Chang wrote:
> This series implements mitigations for lack of DMA access control on
> sys
On 9/26/2019 4:20 AM, Robin Murphy wrote:
> On 2019-09-26 11:44 am, Nicolas Saenz Julienne wrote:
>> Robin, have you looked into supporting multiple dma-ranges? It's the
>> next thing
>> we need for BCM STB's PCIe. I'll have a go at it myself if nothing
>> is in
>> the
>>
29 matches
Mail list logo
