* Re: [PATCH v3 2/6] PCI: uniphier: Add misc interrupt handler to invoke PME and AER
From: Kunihiko Hayashi @ 2020-06-05 2:36 UTC (permalink / raw)
To: Marc Zyngier
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-pci, linux-kernel, Masahiro Yamada, Rob Herring,
Gustavo Pimentel, Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <9cbfdacba32c5e351fd9e14444768666@kernel.org>
Hi Marc,
On 2020/06/04 19:11, Marc Zyngier wrote:
> On 2020-06-04 10:43, Kunihiko Hayashi wrote:
>
> [...]
>
>>>> -static void uniphier_pcie_irq_handler(struct irq_desc *desc)
>>>> +static void uniphier_pcie_misc_isr(struct pcie_port *pp)
>>>> {
>>>> - struct pcie_port *pp = irq_desc_get_handler_data(desc);
>>>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>>>> struct uniphier_pcie_priv *priv = to_uniphier_pcie(pci);
>>>> - struct irq_chip *chip = irq_desc_get_chip(desc);
>>>> - unsigned long reg;
>>>> - u32 val, bit, virq;
>>>> + u32 val, virq;
>>>>
>>>> - /* INT for debug */
>>>> val = readl(priv->base + PCL_RCV_INT);
>>>>
>>>> if (val & PCL_CFG_BW_MGT_STATUS)
>>>> dev_dbg(pci->dev, "Link Bandwidth Management Event\n");
>>>> +
>>>> if (val & PCL_CFG_LINK_AUTO_BW_STATUS)
>>>> dev_dbg(pci->dev, "Link Autonomous Bandwidth Event\n");
>>>> - if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "Root Error\n");
>>>> - if (val & PCL_CFG_PME_MSI_STATUS)
>>>> - dev_dbg(pci->dev, "PME Interrupt\n");
>>>> +
>>>> + if (pci_msi_enabled()) {
>>>
>>> This checks whether the kernel supports MSIs. Not that they are
>>> enabled in your controller. Is that really what you want to do?
>>
>> The below two status bits are valid when the interrupt for MSI is asserted.
>> That is, pci_msi_enabled() is wrong.
>>
>> I'll modify the function to check the two bits only if this function is
>> called from MSI handler.
>>
>>>
>>>> + if (val & PCL_CFG_AER_RC_ERR_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "Root Error Status\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>> +
>>>> + if (val & PCL_CFG_PME_MSI_STATUS) {
>>>> + dev_dbg(pci->dev, "PME Interrupt\n");
>>>> + virq = irq_linear_revmap(pp->irq_domain, 0);
>>>> + generic_handle_irq(virq);
>>>> + }
>>>
>>> These two cases do the exact same thing, calling the same interrupt.
>>> What is the point of dealing with them independently?
>>
>> Both PME and AER are asserted from MSI-0, and each handler checks its own
>> status bit in the PCIe register (aer_irq() in pcie/aer.c and pcie_pme_irq()
>> in pcie/pme.c).
>> So I think this handler calls generic_handle_irq() for the same MSI-0.
>
> So what is wrong with
>
> if (val & (PCL_CFG_AER_RC_ERR_MSI_STATUS |
> PCL_CFG_PME_MSI_STATUS)) {
> // handle interrupt
> }
>
> ?
No problem.
I'll rewrite it in the same way as yours in handling interrupts.
> If you have two handlers for the same interrupt, this is a shared
> interrupt and each handler will be called in turn.
Yes, MSI-0 is shared with PME and AER, and it will be like that.
Thank you,
---
Best Regards
Kunihiko Hayashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: John Donnelly @ 2020-06-05 2:26 UTC (permalink / raw)
To: Nicolas Saenz Julienne, Bhupesh Sharma
Cc: Devicetree List, Arnd Bergmann, Baoquan He,
Linux Doc Mailing List, chenzhou, Catalin Marinas, RuiRui Yang,
Prabhakar Kushwaha, kexec mailing list, Linux Kernel Mailing List,
Rob Herring, Simon Horman, James Morse, guohanjun,
Thomas Gleixner, Prabhakar Kushwaha, Will Deacon, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <751bbe2512628ff38002db33ce02af051d080cd2.camel@suse.de>
On 6/4/20 12:01 PM, Nicolas Saenz Julienne wrote:
> On Thu, 2020-06-04 at 01:17 +0530, Bhupesh Sharma wrote:
>> Hi All,
>>
>> On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com>
>> wrote:
>>>
>>>> On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>> On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
>>>>> Hi Chen,
>>>>>
>>>>> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com
>>>>>> wrote:
>>>>>>
>>>>>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <
>>>>>>> prabhakar.pkin@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <
>>>>>>> john.p.donnelly@oracle.com> wrote:
>>>>>>>> Hi . See below !
>>>>>>>>
>>>>>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi John,
>>>>>>>>>
>>>>>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <
>>>>>>>>> John.P.donnelly@oracle.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
>>>>>>>>>>> Hi Chen,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <
>>>>>>>>>>> chenzhou10@huawei.com> wrote:
>>>>>>>>>>>> This patch series enable reserving crashkernel above 4G in
>>>>>>>>>>>> arm64.
>>>>>>>>>>>>
>>>>>>>>>>>> There are following issues in arm64 kdump:
>>>>>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G,
>>>>>>>>>>>> which will fail
>>>>>>>>>>>> when there is no enough low memory.
>>>>>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve
>>>>>>>>>>>> crashkernel above 4G,
>>>>>>>>>>>> in this case, if swiotlb or DMA buffers are required,
>>>>>>>>>>>> crash dump kernel
>>>>>>>>>>>> will boot failure because there is no low memory available
>>>>>>>>>>>> for allocation.
>>>>>>>>>>>>
>>>>>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump
>>>>>>>>>>> kernel
>>>>>>>>>>> with bootargs as [2] of primary kernel.
>>>>>>>>>>> This error observed on ThunderX2 ARM64 platform.
>>>>>>>>>>>
>>>>>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this
>>>>>>>>>>> patch set
>>>>>>>>>>> and
>>>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
>>>>>>>>>>> Also **without** this patch-set
>>>>>>>>>>> "
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
>>>>>>>>>>> "
>>>>>>>>>>>
>>>>>>>>>>> This issue comes whenever crashkernel memory is reserved
>>>>>>>>>>> after 0xc000_0000.
>>>>>>>>>>> More details discussed earlier in
>>>>>>>>>>>
> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$
> without
>>>>>>>>>>> any
>>>>>>>>>>> solution
>>>>>>>>>>>
>>>>>>>>>>> This patch-set is expected to solve similar kind of issue.
>>>>>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above
>>>>>>>>>>> mentioned
>>>>>>>>>>> observation should be considered/fixed. .
>>>>>>>>>>>
>>>>>>>>>>> --pk
>>>>>>>>>>>
>>>>>>>>>>> [1]
>>>>>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.367696] NET: Registered protocol family 16
>>>>>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
>>>>>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
>>>>>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
>>>>>>>>>>> 5.7.0-rc3+ #121
>>>>>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
>>>>>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
>>>>>>>>>>> [ 30.369984] Call trace:
>>>>>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
>>>>>>>>>>> [ 30.369991] show_stack+0x20/0x30
>>>>>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
>>>>>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
>>>>>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0
>>>>>>>>>>> xb50
>>>>>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
>>>>>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
>>>>>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
>>>>>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
>>>>>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
>>>>>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
>>>>>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
>>>>>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
>>>>>>>>>>> [ 30.370036] Mem-Info:
>>>>>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
>>>>>>>>>>> [ 30.370064] active_file:0 inactive_file:0
>>>>>>>>>>> isolated_file:0
>>>>>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
>>>>>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
>>>>>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
>>>>>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
>>>>>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> isolated(anon):0kB
>>>>>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB
>>>>>>>>>>> shmem:0kB
>>>>>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
>>>>>>>>>>> writeback_tmp:0kB
>>>>>>>>>>> unstable:0kB all_unreclaimable? no
>>>>>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
>>>>>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB
>>>>>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
>>>>>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
>>>>>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB
>>>>>>>>>>> low:664kB
>>>>>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:269700kB managed:256000kB mlocked:0kB
>>>>>>>>>>> kernel_stack:0kB
>>>>>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
>>>>>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB
>>>>>>>>>>> low:15504kB
>>>>>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB
>>>>>>>>>>> inactive_anon:0kB
>>>>>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB
>>>>>>>>>>> writepending:0kB
>>>>>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB
>>>>>>>>>>> kernel_stack:21672kB
>>>>>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB
>>>>>>>>>>> free_cma:0kB
>>>>>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
>>>>>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB
>>>>>>>>>>> 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
>>>>>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB
>>>>>>>>>>> 0*64kB 0*128kB
>>>>>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) =
>>>>>>>>>>> 256000kB
>>>>>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB
>>>>>>>>>>> (UE) 3*32kB
>>>>>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME)
>>>>>>>>>>> 3*1024kB (ME)
>>>>>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
>>>>>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
>>>>>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
>>>>>>>>>>> [ 30.370130] 0 total pagecache pages
>>>>>>>>>>> [ 30.370132] 0 pages in swap cache
>>>>>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
>>>>>>>>>>> [ 30.370135] Free swap = 0kB
>>>>>>>>>>> [ 30.370136] Total swap = 0kB
>>>>>>>>>>> [ 30.370137] 2164609 pages RAM
>>>>>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
>>>>>>>>>>> [ 30.370140] 612331 pages reserved
>>>>>>>>>>> [ 30.370141] 0 pages hwpoisoned
>>>>>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for
>>>>>>>>>>> atomic
>>>>>>>>>>> coherent allocation
>>>>>>>>>> During my testing I saw the same error and Chen's solution
>>>>>>>>>> corrected it .
>>>>>>>>> Which combination you are using on your side? I am using
>>>>>>>>> Prabhakar's
>>>>>>>>> suggested environment and can reproduce the issue
>>>>>>>>> with or without Chen's crashkernel support above 4G patchset.
>>>>>>>>>
>>>>>>>>> I am also using a ThunderX2 platform with latest makedumpfile
>>>>>>>>> code and
>>>>>>>>> kexec-tools (with the suggested patch
>>>>>>>>> <
>>>>>>>>>
> https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$
>>>>>>>>>> ).
>>>>>>>>> Thanks,
>>>>>>>>> Bhupesh
>>>>>>>> I did this activity 5 months ago and I have moved on to other
>>>>>>>> activities. My DMA failures were related to PCI devices that could
>>>>>>>> not be enumerated because low-DMA space was not available when
>>>>>>>> crashkernel was moved above 4G; I don’t recall the exact platform.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For this failure ,
>>>>>>>>
>>>>>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
>>>>>>>>>>> coherent allocation
>>>>>>>> Is due to :
>>>>>>>>
>>>>>>>>
>>>>>>>> 3618082c
>>>>>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
>>>>>>>>
>>>>>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
>>>>>>>> region below 1G, the crashkernel is placed in the upper 4G
>>>>>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
>>>>>>>> to the ZONE_DMA region, it prints out call trace during bootup.
>>>>>>>>
>>>>>>>> It is due to having this CONFIG item ON :
>>>>>>>>
>>>>>>>>
>>>>>>>> CONFIG_ZONE_DMA=y
>>>>>>>>
>>>>>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
>>>>>>>> use the device tree to specify memory below 1G.
>>>>>>>>
>>>>>>>>
>>>>>>> Disabling ZONE_DMA is temporary solution. We may need proper
>>>>>>> solution
>>>>>> Perhaps the Raspberry platform configuration dependencies need
>>>>>> separated from “server class” Arm equipment ? Or auto-configured on
>>>>>> boot ? Consult an expert ;-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> I would like to see Chen’s feature added , perhaps as
>>>>>>>> EXPERIMENTAL, so we can get some configuration testing done on
>>>>>>>> it. It corrects having a DMA zone in low memory while crash-
>>>>>>>> kernel is above 4GB. This has been going on for a year now.
>>>>>>> I will also like this patch to be added in Linux as early as
>>>>>>> possible.
>>>>>>>
>>>>>>> Issue mentioned by me happens with or without this patch.
>>>>>>>
>>>>>>> This patch-set can consider fixing because it uses low memory for
>>>>>>> DMA
>>>>>>> & swiotlb only.
>>>>>>> We can consider restricting crashkernel within the required range
>>>>>>> like below
>>>>>>>
>>>>>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>>>>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
>>>>>>> --- a/kernel/crash_core.c
>>>>>>> +++ b/kernel/crash_core.c
>>>>>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size,
>>>>>>> CRASH_ALIGN);
>>>>>>> if (!low_base) {
>>>>>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
>>>>>>> please try smaller size.\n",
>>>>>>> (unsigned long)(low_size >> 20));
>>>>>>>
>>>>>>>
>>>>>> I suspect 0xc0000000 would need to be a CONFIG item and not
>>>>>> hard-coded.
>>>>>>
>>>>> if you consider this as valid change, can you please incorporate as
>>>>> part of your patch-set.
>>>> After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32"),the 0-
>>>> 4G memory is splited
>>>> to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem
>>>> 0x0000000040000000-0x00000000ffffffff] on arm64.
>>>>
>>>> From the above discussion, on your platform, the low crashkernel fall in
>>>> DMA32 region, but your environment needs to access DMA
>>>> region, so there is the call trace.
>>>>
>>>> I have a question, why do you choose 0xc0000000 here?
>>>>
>>>> Besides, this is common code, we also need to consider about x86.
>>>>
>>> + nsaenzjulienne@suse.de
> Thanks for adding me to the conversation, and sorry for the headaches.
>
>>> Exactly . This is why it needs to be a CONFIG option for Raspberry
>>> .., or device tree option.
>>>
>>>
>>> We could revert 1a8e1cef7 since it broke Arm kdump too.
>> Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
>> both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
>> list, thus we couldn't get many eyes on it for a thorough review from
>> kexec/kdump p-o-v.
>>
>> Also we historically never had distinction in common arch code on the
>> basis of the intended end use-case: embedded, server or automotive, so
>> I am not sure introducing a Raspberry specific CONFIG option would be
>> a good idea.
> +1
>
> From the distros perspective it's very important to keep a single kernel image.
>
>> So, rather than reverting the patch, we can look at addressing the
>> same properly this time - especially from a kdump p-o-v.
>> This issue has been reported by some Red Hat arm64 partners with
>> upstream kernel also and as we have noticed in the past as well,
>> hardcoding the placement of the crashkernel base address (unless the
>> base address is specified by a crashkernel=X@Y like bootargs) is also
>> not a portable suggestion.
>>
>> I am working on a possible fix and will have more updates on the same
>> in a day-or-two.
> Please keep me in the loop, we've also had issues pointing to this reported by
> SUSE partners. I can do some testing both on the RPi4 and on big servers that
> need huge crashkernel sizes.
>
> Regards,
> Nicolas
>
Hi Nicolas,
You want want to review this topic with the various email threads . It
has been a long journey.
[1]:https://urldefense.com/v3/__http://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJwQs3C4x$
[v1]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/2/1174__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6e-mIEp$
[v2]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/86__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJyUVjUta$
[v3]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/9/306__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ3CXBRdT$
[v4]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/4/15/273__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ7SxW1Vj$
[v5]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/5/6/1360__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ2wyJ9tj$
[v6]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/8/30/142__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJzvGhWBh$
[v7]:https://urldefense.com/v3/__https://lkml.org/lkml/2019/12/23/411__;!!GqivPVa7Brio!NHQIQVbVz5bR1SSP7U7SwT3uHb6OnycPGa6nM0oLTaQdZT4pjRsjrMjn5GqOJ6pAg6tX$
Chen Zhou (5):
x86: kdump: move reserve_crashkernel_low() into crash_core.c
arm64: kdump: reserve crashkenel above 4G for crash dump kernel
arm64: kdump: add memory for devices by DT property, low-memory-range
kdump: update Documentation about crashkernel on arm64
dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
Documentation/admin-guide/kdump/kdump.rst | 13 ++-
.../admin-guide/kernel-parameters.txt | 12 ++-
Documentation/devicetree/bindings/chosen.txt | 25 ++++++
arch/arm64/kernel/setup.c | 8 +-
arch/arm64/mm/init.c | 61 ++++++++++++-
arch/x86/kernel/setup.c | 66 ++------------
include/linux/crash_core.h | 3 +
include/linux/kexec.h | 2 -
kernel/crash_core.c | 85 +++++++++++++++++++
kernel/kexec_core.c | 17 ----
10 files changed, 208 insertions(+), 84 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V3 3/3] firmware: imx: scu-pd: add more cm4 resources
From: peng.fan @ 2020-06-05 1:59 UTC (permalink / raw)
To: shawnguo, s.hauer, aisheng.dong
Cc: Peng Fan, festevam, qiangqing.zhang, linux, franck.lenormand,
linux-arm-kernel, kernel, leonard.crestez, daniel.baluta,
linux-kernel, linux-imx
In-Reply-To: <1591322372-3793-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add more cm4 resources, then linux could use cm4's i2c/lpuart and
could kick cm4 core.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/imx/scu-pd.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index d1b313fa7b96..af3d6d9ead28 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,18 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
/* CM40 SS */
- { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
- { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+ { "cm40-i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+ { "cm40-intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
+ { "cm40-pid", IMX_SC_R_M4_0_PID0, 5, true, 0},
+ { "cm40-mu-a1", IMX_SC_R_M4_0_MU_1A, 1, false, 0},
+ { "cm40-lpuart", IMX_SC_R_M4_0_UART, 1, false, 0},
+
+ /* CM41 SS */
+ { "cm41-i2c", IMX_SC_R_M4_1_I2C, 1, false, 0 },
+ { "cm41-intmux", IMX_SC_R_M4_1_INTMUX, 1, false, 0 },
+ { "cm41-pid", IMX_SC_R_M4_1_PID0, 5, true, 0},
+ { "cm41-mu-a1", IMX_SC_R_M4_1_MU_1A, 1, false, 0},
+ { "cm41-lpuart", IMX_SC_R_M4_1_UART, 1, false, 0},
};
static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 2/3] firmware: imx: add resource management api
From: peng.fan @ 2020-06-05 1:59 UTC (permalink / raw)
To: shawnguo, s.hauer, aisheng.dong
Cc: Peng Fan, festevam, qiangqing.zhang, linux, franck.lenormand,
linux-arm-kernel, kernel, leonard.crestez, daniel.baluta,
linux-kernel, linux-imx
In-Reply-To: <1591322372-3793-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add resource management API, when we have multiple
partition running together, resources not owned to current
partition should not be used.
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/imx/Makefile | 2 +-
drivers/firmware/imx/rm.c | 45 ++++++++++++++++++++++++
include/linux/firmware/imx/sci.h | 1 +
include/linux/firmware/imx/svc/rm.h | 69 +++++++++++++++++++++++++++++++++++++
4 files changed, 116 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/imx/rm.c
create mode 100644 include/linux/firmware/imx/svc/rm.h
diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile
index 08bc9ddfbdfb..17ea3613e142 100644
--- a/drivers/firmware/imx/Makefile
+++ b/drivers/firmware/imx/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_IMX_DSP) += imx-dsp.o
-obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o
+obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o rm.o
obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
diff --git a/drivers/firmware/imx/rm.c b/drivers/firmware/imx/rm.c
new file mode 100644
index 000000000000..a12db6ff323b
--- /dev/null
+++ b/drivers/firmware/imx/rm.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ *
+ * File containing client-side RPC functions for the RM service. These
+ * function are ported to clients that communicate to the SC.
+ */
+
+#include <linux/firmware/imx/svc/rm.h>
+
+struct imx_sc_msg_rm_rsrc_owned {
+ struct imx_sc_rpc_msg hdr;
+ u16 resource;
+} __packed __aligned(4);
+
+/*
+ * This function check @resource is owned by current partition or not
+ *
+ * @param[in] ipc IPC handle
+ * @param[in] resource resource the control is associated with
+ *
+ * @return Returns 0 for not owned and 1 for owned.
+ */
+bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
+{
+ struct imx_sc_msg_rm_rsrc_owned msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_RM;
+ hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
+ hdr->size = 2;
+
+ msg.resource = resource;
+
+ /*
+ * SCU firmware only returns value 0 or 1
+ * for resource owned check which means not owned or owned.
+ * So it is always successful.
+ */
+ imx_scu_call_rpc(ipc, &msg, true);
+
+ return hdr->func;
+}
+EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
diff --git a/include/linux/firmware/imx/sci.h b/include/linux/firmware/imx/sci.h
index 3fa418a4ca67..3c459f54a88f 100644
--- a/include/linux/firmware/imx/sci.h
+++ b/include/linux/firmware/imx/sci.h
@@ -14,6 +14,7 @@
#include <linux/firmware/imx/svc/misc.h>
#include <linux/firmware/imx/svc/pm.h>
+#include <linux/firmware/imx/svc/rm.h>
int imx_scu_enable_general_irq_channel(struct device *dev);
int imx_scu_irq_register_notifier(struct notifier_block *nb);
diff --git a/include/linux/firmware/imx/svc/rm.h b/include/linux/firmware/imx/svc/rm.h
new file mode 100644
index 000000000000..456b6a59d29b
--- /dev/null
+++ b/include/linux/firmware/imx/svc/rm.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2020 NXP
+ *
+ * Header file containing the public API for the System Controller (SC)
+ * Resource Management (RM) function. This includes functions for
+ * partitioning resources, pads, and memory regions.
+ *
+ * RM_SVC (SVC) Resource Management Service
+ *
+ * Module for the Resource Management (RM) service.
+ */
+
+#ifndef _SC_RM_API_H
+#define _SC_RM_API_H
+
+#include <linux/firmware/imx/sci.h>
+
+/*
+ * This type is used to indicate RPC RM function calls.
+ */
+enum imx_sc_rm_func {
+ IMX_SC_RM_FUNC_UNKNOWN = 0,
+ IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
+ IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
+ IMX_SC_RM_FUNC_PARTITION_FREE = 2,
+ IMX_SC_RM_FUNC_GET_DID = 26,
+ IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
+ IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
+ IMX_SC_RM_FUNC_GET_PARTITION = 5,
+ IMX_SC_RM_FUNC_SET_PARENT = 6,
+ IMX_SC_RM_FUNC_MOVE_ALL = 7,
+ IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
+ IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
+ IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
+ IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
+ IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
+ IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS = 12,
+ IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
+ IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
+ IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
+ IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
+ IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
+ IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
+ IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
+ IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
+ IMX_SC_RM_FUNC_MEMREG_FREE = 18,
+ IMX_SC_RM_FUNC_FIND_MEMREG = 30,
+ IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
+ IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
+ IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
+ IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
+ IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
+ IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
+ IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
+ IMX_SC_RM_FUNC_DUMP = 27,
+};
+
+#if IS_ENABLED(CONFIG_IMX_SCU)
+bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource);
+#else
+static inline bool
+imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc, u16 resource)
+{
+ return true;
+}
+#endif
+#endif
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 1/3] firmware: imx: scu-pd: fix cm40 power domain
From: peng.fan @ 2020-06-05 1:59 UTC (permalink / raw)
To: shawnguo, s.hauer, aisheng.dong
Cc: Peng Fan, festevam, qiangqing.zhang, linux, franck.lenormand,
linux-arm-kernel, kernel, leonard.crestez, daniel.baluta,
linux-kernel, linux-imx
In-Reply-To: <1591322372-3793-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The postfix needs to be false. Alought compiler use 0 for postfix now,
and take start_from as 0, it is better we add explicit false to postfix.
Fixes: 705dcca91d0a("firmware: imx: scu-pd: add power domain for I2C and INTMUX in CM40 SS")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
---
drivers/firmware/imx/scu-pd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/imx/scu-pd.c b/drivers/firmware/imx/scu-pd.c
index fb5523aa16ee..d1b313fa7b96 100644
--- a/drivers/firmware/imx/scu-pd.c
+++ b/drivers/firmware/imx/scu-pd.c
@@ -167,8 +167,8 @@ static const struct imx_sc_pd_range imx8qxp_scu_pd_ranges[] = {
{ "dc0-pll", IMX_SC_R_DC_0_PLL_0, 2, true, 0 },
/* CM40 SS */
- { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, 0 },
- { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, 0 },
+ { "cm40_i2c", IMX_SC_R_M4_0_I2C, 1, false, 0 },
+ { "cm40_intmux", IMX_SC_R_M4_0_INTMUX, 1, false, 0 },
};
static const struct imx_sc_pd_soc imx8qxp_scu_pd = {
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V3 0/3] firmware: imx: fix/update cm4 and add resource check
From: peng.fan @ 2020-06-05 1:59 UTC (permalink / raw)
To: shawnguo, s.hauer, aisheng.dong
Cc: Peng Fan, festevam, qiangqing.zhang, linux, franck.lenormand,
linux-arm-kernel, kernel, leonard.crestez, daniel.baluta,
linux-kernel, linux-imx
From: Peng Fan <peng.fan@nxp.com>
V3:
Fix comments
Add R-b tag
V2:
Add R-b tag
Drop patch 3/4 from V1
Add comments and update Copyright for patch 2/3
keep code consistency in Patch 3/3
V1:
https://patchwork.kernel.org/cover/11505045/
Fix cm40 power domain, update to add more cm4 resources
Add resource owner check, to not register if not owned by Linux.
Peng Fan (3):
firmware: imx: scu-pd: fix cm40 power domain
firmware: imx: add resource management api
firmware: imx: scu-pd: add more cm4 resources
drivers/firmware/imx/Makefile | 2 +-
drivers/firmware/imx/rm.c | 45 ++++++++++++++++++++++++
drivers/firmware/imx/scu-pd.c | 14 ++++++--
include/linux/firmware/imx/sci.h | 1 +
include/linux/firmware/imx/svc/rm.h | 69 +++++++++++++++++++++++++++++++++++++
5 files changed, 128 insertions(+), 3 deletions(-)
create mode 100644 drivers/firmware/imx/rm.c
create mode 100644 include/linux/firmware/imx/svc/rm.h
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 03/11] irqchip: add sl28cpld interrupt controller support
From: kernel test robot @ 2020-06-05 1:26 UTC (permalink / raw)
To: Michael Walle, linux-gpio, devicetree, linux-kernel, linux-hwmon,
linux-pwm, linux-watchdog, linux-arm-kernel
Cc: Bartosz Golaszewski, Linus Walleij, Rob Herring, kbuild-all
In-Reply-To: <20200604211039.12689-4-michael@walle.cc>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
Hi Michael,
I love your patch! Perhaps something to improve:
[auto build test WARNING on next-20200604]
[cannot apply to gpio/for-next hwmon/hwmon-next ljones-mfd/for-mfd-next shawnguo/for-next v5.7 v5.7-rc7 v5.7-rc6 v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Michael-Walle/Add-support-for-Kontron-sl28cpld/20200605-051333
base: d4899e5542c15062cc55cac0ca99025bb64edc61
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
drivers/irqchip/irq-sl28cpld.c: In function 'sl28cpld_intc_probe':
>> drivers/irqchip/irq-sl28cpld.c:56:10: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
56 | if (irq < 0)
| ^
vim +56 drivers/irqchip/irq-sl28cpld.c
35
36 static int sl28cpld_intc_probe(struct platform_device *pdev)
37 {
38 struct device *dev = &pdev->dev;
39 struct sl28cpld_intc *irqchip;
40 unsigned int irq;
41 u32 base;
42 int ret;
43
44 if (!dev->parent)
45 return -ENODEV;
46
47 irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
48 if (!irqchip)
49 return -ENOMEM;
50
51 irqchip->regmap = dev_get_regmap(dev->parent, NULL);
52 if (!irqchip->regmap)
53 return -ENODEV;
54
55 irq = platform_get_irq(pdev, 0);
> 56 if (irq < 0)
57 return irq;
58
59 ret = device_property_read_u32(&pdev->dev, "reg", &base);
60 if (ret)
61 return -EINVAL;
62
63 irqchip->chip.name = "sl28cpld-intc";
64 irqchip->chip.irqs = sl28cpld_irqs;
65 irqchip->chip.num_irqs = ARRAY_SIZE(sl28cpld_irqs);
66 irqchip->chip.num_regs = 1;
67 irqchip->chip.status_base = base + INTC_IP;
68 irqchip->chip.mask_base = base + INTC_IE;
69 irqchip->chip.mask_invert = true,
70 irqchip->chip.ack_base = base + INTC_IP;
71
72 return devm_regmap_add_irq_chip_np(&pdev->dev, dev->of_node,
73 irqchip->regmap, irq,
74 IRQF_SHARED | IRQF_ONESHOT, 0,
75 &irqchip->chip, &irqchip->irq_data);
76 }
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 66540 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 4/4] iommu/arm-smmu-nvidia: fix the warning reported by kbuild test robot
From: Krishna Reddy @ 2020-06-04 23:44 UTC (permalink / raw)
Cc: snikam, mperttunen, kbuild test robot, bhuntsman, will, joro,
linux-kernel, praithatha, talho, iommu, nicolinc, linux-tegra,
yhsu, treding, robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200604234414.21912-1-vdumpa@nvidia.com>
>> drivers/iommu/arm-smmu-nvidia.c:151:33: sparse: sparse: cast removes
>> address space '<asn:2>' of expression
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
drivers/iommu/arm-smmu-nvidia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index 5999b6a770992..6348d8dc17fc2 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -248,7 +248,7 @@ struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
break;
nsmmu->bases[i] = devm_ioremap_resource(dev, res);
if (IS_ERR(nsmmu->bases[i]))
- return (struct arm_smmu_device *)nsmmu->bases[i];
+ return ERR_CAST(nsmmu->bases[i]);
nsmmu->num_inst++;
}
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 3/4] iommu/arm-smmu: Add global/context fault implementation hooks
From: Krishna Reddy @ 2020-06-04 23:44 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200604234414.21912-1-vdumpa@nvidia.com>
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
drivers/iommu/arm-smmu-nvidia.c | 100 ++++++++++++++++++++++++++++++++
drivers/iommu/arm-smmu.c | 11 +++-
drivers/iommu/arm-smmu.h | 3 +
3 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index dafc293a45217..5999b6a770992 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -117,6 +117,104 @@ static int nsmmu_reset(struct arm_smmu_device *smmu)
return 0;
}
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+ return container_of(dom, struct arm_smmu_domain, domain);
+}
+
+static irqreturn_t nsmmu_global_fault_inst(int irq,
+ struct arm_smmu_device *smmu,
+ int inst)
+{
+ u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+
+ gfsr = readl_relaxed(nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+ gfsynr0 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR0);
+ gfsynr1 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR1);
+ gfsynr2 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+ ARM_SMMU_GR0_sGFSYNR2);
+
+ if (!gfsr)
+ return IRQ_NONE;
+
+ dev_err_ratelimited(smmu->dev,
+ "Unexpected global fault, this could be serious\n");
+ dev_err_ratelimited(smmu->dev,
+ "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 0x%08x\n",
+ gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+ writel_relaxed(gfsr, nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_global_fault(int irq, void *dev)
+{
+ int inst;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct arm_smmu_device *smmu = dev;
+
+ for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+ irq_ret = nsmmu_global_fault_inst(irq, smmu, inst);
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+
+ return irq_ret;
+}
+
+static irqreturn_t nsmmu_context_fault_bank(int irq,
+ struct arm_smmu_device *smmu,
+ int idx, int inst)
+{
+ u32 fsr, fsynr, cbfrsynra;
+ unsigned long iova;
+
+ fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+ if (!(fsr & ARM_SMMU_FSR_FAULT))
+ return IRQ_NONE;
+
+ fsynr = readl_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FSYNR0);
+ iova = readq_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FAR);
+ cbfrsynra = readl_relaxed(nsmmu_page(smmu, inst, 1) +
+ ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+ dev_err_ratelimited(smmu->dev,
+ "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, cbfrsynra=0x%x, cb=%d\n",
+ fsr, iova, fsynr, cbfrsynra, idx);
+
+ writel_relaxed(fsr, nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FSR);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_context_fault(int irq, void *dev)
+{
+ int inst, idx;
+ irqreturn_t irq_ret = IRQ_NONE;
+ struct iommu_domain *domain = dev;
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+ struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+ for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+ /* Interrupt line shared between all context faults.
+ * Check for faults across all contexts.
+ */
+ for (idx = 0; idx < smmu->num_context_banks; idx++) {
+ irq_ret = nsmmu_context_fault_bank(irq, smmu,
+ idx, inst);
+
+ if (irq_ret == IRQ_HANDLED)
+ return irq_ret;
+ }
+ }
+
+ return irq_ret;
+}
+
static const struct arm_smmu_impl nvidia_smmu_impl = {
.read_reg = nsmmu_read_reg,
.write_reg = nsmmu_write_reg,
@@ -124,6 +222,8 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
.write_reg64 = nsmmu_write_reg64,
.reset = nsmmu_reset,
.tlb_sync = nsmmu_tlb_sync,
+ .global_fault = nsmmu_global_fault,
+ .context_fault = nsmmu_context_fault,
};
struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 243bc4cb2705b..d720e1e191176 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -673,6 +673,7 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
enum io_pgtable_fmt fmt;
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
+ irqreturn_t (*context_fault)(int irq, void *dev);
mutex_lock(&smmu_domain->init_mutex);
if (smmu_domain->smmu)
@@ -835,7 +836,9 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
* handler seeing a half-initialised domain state.
*/
irq = smmu->irqs[smmu->num_global_irqs + cfg->irptndx];
- ret = devm_request_irq(smmu->dev, irq, arm_smmu_context_fault,
+ context_fault = (smmu->impl && smmu->impl->context_fault) ?
+ smmu->impl->context_fault : arm_smmu_context_fault;
+ ret = devm_request_irq(smmu->dev, irq, context_fault,
IRQF_SHARED, "arm-smmu-context-fault", domain);
if (ret < 0) {
dev_err(smmu->dev, "failed to request context IRQ %d (%u)\n",
@@ -2107,6 +2110,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
struct arm_smmu_device *smmu;
struct device *dev = &pdev->dev;
int num_irqs, i, err;
+ irqreturn_t (*global_fault)(int irq, void *dev);
smmu = devm_kzalloc(dev, sizeof(*smmu), GFP_KERNEL);
if (!smmu) {
@@ -2193,9 +2197,12 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
smmu->num_context_irqs = smmu->num_context_banks;
}
+ global_fault = (smmu->impl && smmu->impl->global_fault) ?
+ smmu->impl->global_fault : arm_smmu_global_fault;
+
for (i = 0; i < smmu->num_global_irqs; ++i) {
err = devm_request_irq(smmu->dev, smmu->irqs[i],
- arm_smmu_global_fault,
+ global_fault,
IRQF_SHARED,
"arm-smmu global fault",
smmu);
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index d88374b68da31..f8ce34c07d961 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -18,6 +18,7 @@
#include <linux/io-64-nonatomic-hi-lo.h>
#include <linux/io-pgtable.h>
#include <linux/iommu.h>
+#include <linux/irqreturn.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
#include <linux/types.h>
@@ -387,6 +388,8 @@ struct arm_smmu_impl {
void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
int status);
int (*def_domain_type)(struct device *dev);
+ irqreturn_t (*global_fault)(int irq, void *dev);
+ irqreturn_t (*context_fault)(int irq, void *dev);
};
static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int n)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 2/4] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
From: Krishna Reddy @ 2020-06-04 23:44 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200604234414.21912-1-vdumpa@nvidia.com>
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index e3ef1c69d1326..8f7ffd248f303 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -37,6 +37,11 @@ properties:
- qcom,sc7180-smmu-500
- qcom,sdm845-smmu-500
- const: arm,mmu-500
+ - description: NVIDIA SoCs that use more than one "arm,mmu-500"
+ items:
+ - enum:
+ - nvdia,tegra194-smmu-500
+ - const: arm,mmu-500
- items:
- const: arm,mmu-500
- const: arm,smmu-v2
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 1/4] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
From: Krishna Reddy @ 2020-06-04 23:44 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
In-Reply-To: <20200604234414.21912-1-vdumpa@nvidia.com>
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 161 ++++++++++++++++++++++++++++++++
drivers/iommu/arm-smmu.h | 1 +
5 files changed, 168 insertions(+), 1 deletion(-)
create mode 100644 drivers/iommu/arm-smmu-nvidia.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 50659d76976b7..118da0893c964 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16572,9 +16572,11 @@ F: drivers/i2c/busses/i2c-tegra.c
TEGRA IOMMU DRIVERS
M: Thierry Reding <thierry.reding@gmail.com>
+R: Krishna Reddy <vdumpa@nvidia.com>
L: linux-tegra@vger.kernel.org
S: Supported
F: drivers/iommu/tegra*
+F: drivers/iommu/arm-smmu-nvidia.c
TEGRA KBC DRIVER
M: Laxman Dewangan <ldewangan@nvidia.com>
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 57cf4ba5e27cb..35542df00da72 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -15,7 +15,7 @@ obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o amd_iommu_quirks.o
obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o
obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-qcom.o arm-smmu-nvidia.o
obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index c75b9d957b702..52c84c30f83e4 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -160,6 +160,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu)
*/
switch (smmu->model) {
case ARM_MMU500:
+ if (of_device_is_compatible(smmu->dev->of_node,
+ "nvidia,tegra194-smmu-500"))
+ return nvidia_smmu_impl_init(smmu);
smmu->impl = &arm_mmu500_impl;
break;
case CAVIUM_SMMUV2:
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
new file mode 100644
index 0000000000000..dafc293a45217
--- /dev/null
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Nvidia ARM SMMU v2 implementation quirks
+// Copyright (C) 2019 NVIDIA CORPORATION. All rights reserved.
+
+#define pr_fmt(fmt) "nvidia-smmu: " fmt
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#include "arm-smmu.h"
+
+/* Tegra194 has three ARM MMU-500 Instances.
+ * Two of them are used together for Interleaved IOVA accesses and
+ * used by Non-Isochronous Hw devices for SMMU translations.
+ * Third one is used for SMMU translations from Isochronous HW devices.
+ * It is possible to use this Implementation to program either
+ * all three or two of the instances identically as desired through
+ * DT node.
+ *
+ * Programming all the three instances identically comes with redundant tlb
+ * invalidations as all three never need to be tlb invalidated for a HW device.
+ *
+ * When Linux Kernel supports multiple SMMU devices, The SMMU device used for
+ * Isochornous HW devices should be added as a separate ARM MMU-500 device
+ * in DT and be programmed independently for efficient tlb invalidates.
+ *
+ */
+#define MAX_SMMU_INSTANCES 3
+
+#define TLB_LOOP_TIMEOUT 1000000 /* 1s! */
+#define TLB_SPIN_COUNT 10
+
+struct nvidia_smmu {
+ struct arm_smmu_device smmu;
+ unsigned int num_inst;
+ void __iomem *bases[MAX_SMMU_INSTANCES];
+};
+
+#define to_nvidia_smmu(s) container_of(s, struct nvidia_smmu, smmu)
+
+#define nsmmu_page(smmu, inst, page) \
+ (((inst) ? to_nvidia_smmu(smmu)->bases[(inst)] : smmu->base) + \
+ ((page) << smmu->pgshift))
+
+static u32 nsmmu_read_reg(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+ return readl_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg(struct arm_smmu_device *smmu,
+ int page, int offset, u32 val)
+{
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+ writel_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}
+
+static u64 nsmmu_read_reg64(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+ return readq_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg64(struct arm_smmu_device *smmu,
+ int page, int offset, u64 val)
+{
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+ writeq_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}
+
+static void nsmmu_tlb_sync(struct arm_smmu_device *smmu, int page,
+ int sync, int status)
+{
+ u32 reg;
+ unsigned int i;
+ unsigned int spin_cnt, delay;
+
+ arm_smmu_writel(smmu, page, sync, 0);
+
+ for (delay = 1; delay < TLB_LOOP_TIMEOUT; delay *= 2) {
+ for (spin_cnt = TLB_SPIN_COUNT; spin_cnt > 0; spin_cnt--) {
+ reg = 0;
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++) {
+ reg |= readl_relaxed(
+ nsmmu_page(smmu, i, page) + status);
+ }
+ if (!(reg & ARM_SMMU_sTLBGSTATUS_GSACTIVE))
+ return;
+ cpu_relax();
+ }
+ udelay(delay);
+ }
+ dev_err_ratelimited(smmu->dev,
+ "TLB sync timed out -- SMMU may be deadlocked\n");
+}
+
+static int nsmmu_reset(struct arm_smmu_device *smmu)
+{
+ u32 reg;
+ unsigned int i;
+
+ for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++) {
+ /* clear global FSR */
+ reg = readl_relaxed(nsmmu_page(smmu, i, ARM_SMMU_GR0) +
+ ARM_SMMU_GR0_sGFSR);
+ writel_relaxed(reg, nsmmu_page(smmu, i, ARM_SMMU_GR0) +
+ ARM_SMMU_GR0_sGFSR);
+ }
+
+ return 0;
+}
+
+static const struct arm_smmu_impl nvidia_smmu_impl = {
+ .read_reg = nsmmu_read_reg,
+ .write_reg = nsmmu_write_reg,
+ .read_reg64 = nsmmu_read_reg64,
+ .write_reg64 = nsmmu_write_reg64,
+ .reset = nsmmu_reset,
+ .tlb_sync = nsmmu_tlb_sync,
+};
+
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
+{
+ unsigned int i;
+ struct nvidia_smmu *nsmmu;
+ struct resource *res;
+ struct device *dev = smmu->dev;
+ struct platform_device *pdev = to_platform_device(smmu->dev);
+
+ nsmmu = devm_kzalloc(smmu->dev, sizeof(*nsmmu), GFP_KERNEL);
+ if (!nsmmu)
+ return ERR_PTR(-ENOMEM);
+
+ nsmmu->smmu = *smmu;
+ /* Instance 0 is ioremapped by arm-smmu.c */
+ nsmmu->num_inst = 1;
+
+ for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ if (!res)
+ break;
+ nsmmu->bases[i] = devm_ioremap_resource(dev, res);
+ if (IS_ERR(nsmmu->bases[i]))
+ return (struct arm_smmu_device *)nsmmu->bases[i];
+ nsmmu->num_inst++;
+ }
+
+ nsmmu->smmu.impl = &nvidia_smmu_impl;
+ devm_kfree(smmu->dev, smmu);
+ pr_info("NVIDIA ARM SMMU Implementation, Instances=%d\n",
+ nsmmu->num_inst);
+
+ return &nsmmu->smmu;
+}
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index d172c024be618..d88374b68da31 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -451,6 +451,7 @@ static inline void arm_smmu_writeq(struct arm_smmu_device *smmu, int page,
struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
+struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
int arm_mmu500_reset(struct arm_smmu_device *smmu);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v6 0/4] Nvidia Arm SMMUv2 Implementation
From: Krishna Reddy @ 2020-06-04 23:44 UTC (permalink / raw)
Cc: snikam, mperttunen, bhuntsman, will, joro, linux-kernel,
praithatha, talho, iommu, nicolinc, linux-tegra, yhsu, treding,
robin.murphy, linux-arm-kernel, bbiswas
Changes in v6:
Restricted the patch set to driver specific patches.
Fixed the cast warning reported by kbuild test robot.
Rebased on git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
v5 - https://lkml.org/lkml/2020/5/21/1114
v4 - https://lkml.org/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (4):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
iommu/arm-smmu: Add global/context fault implementation hooks
iommu/arm-smmu-nvidia: fix the warning reported by kbuild test robot
.../devicetree/bindings/iommu/arm,smmu.yaml | 5 +
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 261 ++++++++++++++++++
drivers/iommu/arm-smmu.c | 11 +-
drivers/iommu/arm-smmu.h | 4 +
7 files changed, 285 insertions(+), 3 deletions(-)
create mode 100644 drivers/iommu/arm-smmu-nvidia.c
base-commit: 431275afdc7155415254aef4bd3816a1b8a2ead0
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/4] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Rob Herring @ 2020-06-04 23:09 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: marex, devicetree, michal.simek, xuwei5, robh+dt,
laurent.pinchart, mcoquelin.stm32, kernel, linux-arm-kernel
In-Reply-To: <20200601063308.13045-5-ricardo.canuelo@collabora.com>
On Mon, 01 Jun 2020 08:33:08 +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
> original binding has been split into two files: adi,adv7511.yaml for
> ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> .../bindings/display/bridge/adi,adv7511.txt | 143 -----------
> .../bindings/display/bridge/adi,adv7511.yaml | 231 ++++++++++++++++++
> .../bindings/display/bridge/adi,adv7533.yaml | 175 +++++++++++++
> 3 files changed, 406 insertions(+), 143 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 07/20] dt-bindings: mtd: Document boolean NAND ECC properties
From: Rob Herring @ 2020-06-04 23:08 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Boris Brezillon, linux-mtd,
Thomas Petazzoni, Mason Yang, linux-arm-kernel
In-Reply-To: <20200603175759.19948-8-miquel.raynal@bootlin.com>
On Wed, Jun 03, 2020 at 07:57:46PM +0200, Miquel Raynal wrote:
> Document nand-use-soft-ecc-engine and nand-no-ecc-engine properties.
> The former is here to force software correction, the latter prevents
> any correction to happen.
>
> These properties (along with nand-ecc-engine) are supposed to be more
> accurate than the current nand-ecc-modes wich is very misleading and
> very often people think it is mandatory while the core should be
> relied upon to decide which correction to handle.
>
> nand-ecc-mode was already inacurate, but it becomes totally
> problematic with setups where there are several hardware engines.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> Documentation/devicetree/bindings/mtd/nand-controller.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> index 0969d2e6720b..a3750978ebb8 100644
> --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml
> @@ -68,6 +68,12 @@ patternProperties:
> 3/ The ECC engine is external, in this case the phandle should
> reference the specific ECC engine node.
>
> + nand-use-soft-ecc-engine: true
> + description: Use a software ECC engine.
Humm, I'm surprised this is valid YAML. nand-use-soft-ecc-engine can't
be both a boolean and a map (aka schema, aka dict).
nand-use-soft-ecc-engine:
type: boolean
description: ...
> +
> + nand-no-ecc-engine: true
> + description: Do not use any ECC correction.
> +
> nand-ecc-placement:
> allOf:
> - $ref: /schemas/types.yaml#/definitions/string
> --
> 2.20.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: Override SPSR.SS when single-stepping is enabled
From: Keno Fischer @ 2020-06-04 22:32 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, Luis Machado, kernel-team, stable, linux-arm-kernel
In-Reply-To: <20200604083210.GC30155@willie-the-truck>
> > With your proposed patch, we instead get
> > <- (ip: 0x0)
> > -> PTRACE_SINGLESTEP
> > <- (ip: 0x4 - seccomp trap)
> > -> PTRACE_SINGLESTEP
> > <- SIGTRAP (ip: 0x8 - TRAP_TRACE trap)
>
> Urgh, and actually, I think this is *only* the case if the seccomp
> handler actually changes a register in the target, right?
Ah yes, you are correct. Because otherwise the flag would not
get toggled at all. That does raise an additional question about
signal stops though, which have a similar issue. What if a single
step gets completed, but the singlestep trap gets pre-empted
by some other signal. What should PTRACE_SINGLESTEP
from such a signal stop do?
> In which case, your proposed patch should probably do something like:
>
> if (dir == PTRACE_SYSCALL_EXIT) {
> bool stepping = test_thread_flag(TIF_SINGLESTEP);
>
> tracehook_report_syscall_exit(regs, stepping);
> user_rewind_single_step(regs);
> }
>
> otherwise I think we could get a spurious SIGTRAP on return to userspace.
> What do you think?
Yes, this change seems reasonable, though you may want to make the
rewind conditional on stepping, since otherwise the armed pstate may
become visible to a signal handler/ptrace signal stop which may
be unexpected.
> This has also got me thinking about your other patch to report a pseudo-step
> exception on entry to a signal handler:
>
> https://lore.kernel.org/r/20200524043827.GA33001@juliacomputing.com
>
> Although we don't actually disarm the step logic there (and so you might
> expect a spurious SIGTRAP on the second instruction of the handler), I
> think it's ok because the tracer will either do PTRACE_SINGLESTEP (and
> rearm the state machine) or PTRACE_CONT (and so stepping will be
> disabled). Do you agree?
Yes, I had thought about whether to re-arm the rewind the single-step logic,
but then realized that since the next event was a ptrace stop anyway, the
ptracer could decide. With your patch here, it would always just depend
on which ptrace continue method is used, which is fine.
> > This is problematic, because the ptracer may want to inspect the
> > result of the syscall instruction. On other architectures, this
> > problem is solved with a pseudo-singlestep trap that gets executed
> > if you resume from a syscall-entry-like trap with PTRACE_SINGLESTEP.
> > See the below patch for the change I'm proposing. There is a slight
> > issue with that patch, still: It now makes the x7 issue apply to the
> > singlestep trap at exit, so we should do the patch to fix that issue
> > before we apply that change (or manually check for this situation
> > and issue the pseudo-singlestep trap manually).
>
> I don't see the dependency on the x7 issue; x7 is nobbled on syscall entry,
> so it will be nobbled in the psuedo-step trap as well as the hardware step
> trap on syscall return. I'd also like to backport this to stable, without
> having to backport an optional extension to the ptrace API for preserving
> x7. Or are you saying that the value of x7 should be PTRACE_SYSCALL_ENTER
> for the pseudo trap? That seems a bit weird to me, but then this is all
> weird anyway.
So the issue here is that writes to x7 at the singlestep stop after a seccomp
stop will now be ignored (and reads incorrect), which is a definite change
in behavior and one that I would not recommend backporting to stable.
If you do want to backport something to stable, I would recommend making
the register modification conditional on !stepping for the backport.
> I think that's still the case with my addition above, so that's good.
> Any other quirks you ran into that we should address here? Now that I have
> this stuff partially paged-in, it would be good to fix a bunch of this
> at once. I can send out a v2 which includes the two patches from you
> once we're agreed on the details.
As for other quirks, the behavior with negative syscalls is a bit odd,
but not necessarily arm64 specific (though arm64 has an additional
quirk). I'd emailed about that separately here:
https://lkml.org/lkml/2020/5/22/1216
There's also the issue that orig_x0 is inaccessible, so syscall
restarts of syscalls that have had their registers modified by a
ptracer will potentially unexpectedly use the x0 value before
modification during restart, rather than the modified values.
My preference would be to fix these two issues along with the
x7 issue, by introducing a new regset that:
- Explicitly splits out orig_x0
- Sets regular x0 to -ENOSYS before the
syscall entry stop (and using the orig_x0 value for syscall processing)
- Addresses the x7 issue
As I said, I'm planning to send a patch along these lines, but
haven't had the time yet. Perhaps this weekend.
Lastly, there was one additional issue with process_vm_readv,
which isn't directly ptrace related, but slightly adjacent (and
also no arm64 specific):
I wrote about that here: https://lkml.org/lkml/2020/5/24/466
I think that's everything I ran into from the kernel perspective,
though I'm not 100% done porting yet, so other things may come
up.
Keno
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [arm:clearfog 9/10] drivers/pci/pcie/aspm.c:579 pcie_aspm_cap_init() warn: inconsistent indenting
From: kernel test robot @ 2020-06-04 21:58 UTC (permalink / raw)
To: Russell King; +Cc: kbuild-all, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 5704 bytes --]
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git clearfog
head: 8db1590173dd1c6bb6861ca938663938c1d832b8
commit: 5315e38eefb72a8444314ef491b730b99baed319 [9/10] mvebu/clearfog pcie updates
config: x86_64-randconfig-m001-20200604 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
smatch warnings:
drivers/pci/pcie/aspm.c:579 pcie_aspm_cap_init() warn: inconsistent indenting
vim +579 drivers/pci/pcie/aspm.c
545
546 static void pcie_aspm_cap_init(struct pcie_link_state *link, int blacklist)
547 {
548 struct pci_dev *child = link->downstream, *parent = link->pdev;
549 struct pci_bus *linkbus = parent->subordinate;
550 struct aspm_register_info upreg, dwreg;
551
552 if (blacklist) {
553 /* Set enabled/disable so that we will disable ASPM later */
554 link->aspm_enabled = ASPM_STATE_ALL;
555 link->aspm_disable = ASPM_STATE_ALL;
556 return;
557 }
558
559 /* Get upstream/downstream components' register state */
560 pcie_get_aspm_reg(parent, &upreg);
561 pcie_get_aspm_reg(child, &dwreg);
562
563 /*
564 * If ASPM not supported, don't mess with the clocks and link,
565 * bail out now.
566 */
567 if (!(upreg.support & dwreg.support))
568 return;
569
570 /* Configure common clock before checking latencies */
571 pcie_aspm_configure_common_clock(link);
572
573 /*
574 * Re-read upstream/downstream components' register state
575 * after clock configuration
576 */
577 pcie_get_aspm_reg(parent, &upreg);
578 pcie_get_aspm_reg(child, &dwreg);
> 579 dev_info(&parent->dev, "up support %x enabled %x\n", upreg.support, upreg.enabled);
580 dev_info(&parent->dev, "dn support %x enabled %x\n", dwreg.support, dwreg.enabled);
581
582 /*
583 * Setup L0s state
584 *
585 * Note that we must not enable L0s in either direction on a
586 * given link unless components on both sides of the link each
587 * support L0s.
588 */
589 if (dwreg.support & upreg.support & PCIE_LINK_STATE_L0S)
590 link->aspm_support |= ASPM_STATE_L0S;
591 if (dwreg.enabled & PCIE_LINK_STATE_L0S)
592 link->aspm_enabled |= ASPM_STATE_L0S_UP;
593 if (upreg.enabled & PCIE_LINK_STATE_L0S)
594 link->aspm_enabled |= ASPM_STATE_L0S_DW;
595 link->latency_up.l0s = calc_l0s_latency(upreg.latency_encoding_l0s);
596 link->latency_dw.l0s = calc_l0s_latency(dwreg.latency_encoding_l0s);
597
598 /* Setup L1 state */
599 if (upreg.support & dwreg.support & PCIE_LINK_STATE_L1)
600 link->aspm_support |= ASPM_STATE_L1;
601 if (upreg.enabled & dwreg.enabled & PCIE_LINK_STATE_L1)
602 link->aspm_enabled |= ASPM_STATE_L1;
603 link->latency_up.l1 = calc_l1_latency(upreg.latency_encoding_l1);
604 link->latency_dw.l1 = calc_l1_latency(dwreg.latency_encoding_l1);
605
606 /* Setup L1 substate */
607 if (upreg.l1ss_cap & dwreg.l1ss_cap & PCI_L1SS_CAP_ASPM_L1_1)
608 link->aspm_support |= ASPM_STATE_L1_1;
609 if (upreg.l1ss_cap & dwreg.l1ss_cap & PCI_L1SS_CAP_ASPM_L1_2)
610 link->aspm_support |= ASPM_STATE_L1_2;
611 if (upreg.l1ss_cap & dwreg.l1ss_cap & PCI_L1SS_CAP_PCIPM_L1_1)
612 link->aspm_support |= ASPM_STATE_L1_1_PCIPM;
613 if (upreg.l1ss_cap & dwreg.l1ss_cap & PCI_L1SS_CAP_PCIPM_L1_2)
614 link->aspm_support |= ASPM_STATE_L1_2_PCIPM;
615
616 if (upreg.l1ss_ctl1 & dwreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_1)
617 link->aspm_enabled |= ASPM_STATE_L1_1;
618 if (upreg.l1ss_ctl1 & dwreg.l1ss_ctl1 & PCI_L1SS_CTL1_ASPM_L1_2)
619 link->aspm_enabled |= ASPM_STATE_L1_2;
620 if (upreg.l1ss_ctl1 & dwreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_1)
621 link->aspm_enabled |= ASPM_STATE_L1_1_PCIPM;
622 if (upreg.l1ss_ctl1 & dwreg.l1ss_ctl1 & PCI_L1SS_CTL1_PCIPM_L1_2)
623 link->aspm_enabled |= ASPM_STATE_L1_2_PCIPM;
624
625 if (link->aspm_support & ASPM_STATE_L1SS)
626 aspm_calc_l1ss_info(link, &upreg, &dwreg);
627
628 /* Save default state */
629 link->aspm_default = link->aspm_enabled;
630
631 /* Setup initial capable state. Will be updated later */
632 link->aspm_capable = link->aspm_support;
633 /*
634 * If the downstream component has pci bridge function, don't
635 * do ASPM for now.
636 */
637 list_for_each_entry(child, &linkbus->devices, bus_list) {
638 if (pci_pcie_type(child) == PCI_EXP_TYPE_PCI_BRIDGE) {
639 link->aspm_disable = ASPM_STATE_ALL;
640 break;
641 }
642 }
643
644 /* Get and check endpoint acceptable latencies */
645 list_for_each_entry(child, &linkbus->devices, bus_list) {
646 u32 reg32, encoding;
647 struct aspm_latency *acceptable =
648 &link->acceptable[PCI_FUNC(child->devfn)];
649
650 if (pci_pcie_type(child) != PCI_EXP_TYPE_ENDPOINT &&
651 pci_pcie_type(child) != PCI_EXP_TYPE_LEG_END)
652 continue;
653
654 pcie_capability_read_dword(child, PCI_EXP_DEVCAP, ®32);
655 /* Calculate endpoint L0s acceptable latency */
656 encoding = (reg32 & PCI_EXP_DEVCAP_L0S) >> 6;
657 acceptable->l0s = calc_l0s_acceptable(encoding);
658 /* Calculate endpoint L1 acceptable latency */
659 encoding = (reg32 & PCI_EXP_DEVCAP_L1) >> 9;
660 acceptable->l1 = calc_l1_acceptable(encoding);
661
662 pcie_aspm_check_latency(child);
663 }
664 }
665
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29910 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/5] Improvements of the stackleak gcc plugin
From: Kees Cook @ 2020-06-04 21:39 UTC (permalink / raw)
To: Alexander Popov
Cc: kernel-hardening, Catalin Marinas, Masahiro Yamada,
Vincenzo Frascino, Will Deacon, Naohiro Aota, Sven Schnelle,
Masahiro Yamada, x86, Emese Revfy, Iurii Zaikin, PaX Team,
Laura Abbott, Mathias Krause, linux-kbuild, Alexander Monakov,
Michal Marek, Thomas Gleixner, Peter Collingbourne,
linux-arm-kernel, notify, Florian Weimer, gcc, Brad Spengler,
linux-kernel, Miguel Ojeda, Luis Chamberlain, Jessica Yu,
Andrew Morton, Thiago Jung Bauermann
In-Reply-To: <20200604134957.505389-1-alex.popov@linux.com>
On Thu, Jun 04, 2020 at 04:49:52PM +0300, Alexander Popov wrote:
> In this patch series I collected various improvements of the stackleak
> gcc plugin.
Great; thank you! I'll take a closer look at this shortly!
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-06-04 21:28 UTC (permalink / raw)
To: linux-kernel
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Scott Branden, lukas, Ray Jui, Rob Herring,
open list:SPI SUBSYSTEM, Mark Brown,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl, Nicolas Saenz Julienne
The 4 SPI controller instances added in BCM2711 and BCM7211 SoCs (SPI3,
SPI4, SPI5 and SPI6) share the same interrupt line with SPI0.
For the BCM2835 case which is deemed performance critical, we would like
to continue using an interrupt handler which does not have the extra
comparison on BCM2835_SPI_CS_INTR.
To support that requirement the common interrupt handling code between
the shared and non-shared interrupt paths is split into a
bcm2835_spi_interrupt_common() and both bcm2835_spi_interrupt() as well
as bcm2835_spi_shared_interrupt() make use of it.
During probe, we determine if there is at least another instance of this
SPI controller, and if there is, then we install a shared interrupt
handler.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- identify other available SPI nodes to determine if we need to set-up
interrupt sharing. This needs to happen for the very first instance
since we cannot know for the first instance whether interrupt sharing
is needed or not.
drivers/spi/spi-bcm2835.c | 61 ++++++++++++++++++++++++++++++++-------
1 file changed, 50 insertions(+), 11 deletions(-)
diff --git a/drivers/spi/spi-bcm2835.c b/drivers/spi/spi-bcm2835.c
index 237bd306c268..0288b5b3de1e 100644
--- a/drivers/spi/spi-bcm2835.c
+++ b/drivers/spi/spi-bcm2835.c
@@ -361,11 +361,10 @@ static void bcm2835_spi_reset_hw(struct spi_controller *ctlr)
bcm2835_wr(bs, BCM2835_SPI_DLEN, 0);
}
-static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+static inline irqreturn_t bcm2835_spi_interrupt_common(struct spi_controller *ctlr,
+ u32 cs)
{
- struct spi_controller *ctlr = dev_id;
struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
- u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
/*
* An interrupt is signaled either if DONE is set (TX FIFO empty)
@@ -394,6 +393,27 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
+static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctlr = dev_id;
+ struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+ u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+ return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
+static irqreturn_t bcm2835_spi_shared_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctlr = dev_id;
+ struct bcm2835_spi *bs = spi_controller_get_devdata(ctlr);
+ u32 cs = bcm2835_rd(bs, BCM2835_SPI_CS);
+
+ if (!(cs & BCM2835_SPI_CS_INTR))
+ return IRQ_NONE;
+
+ return bcm2835_spi_interrupt_common(ctlr, cs);
+}
+
static int bcm2835_spi_transfer_one_irq(struct spi_controller *ctlr,
struct spi_device *spi,
struct spi_transfer *tfr,
@@ -1287,12 +1307,37 @@ static int bcm2835_spi_setup(struct spi_device *spi)
return 0;
}
+static const struct of_device_id bcm2835_spi_match[] = {
+ { .compatible = "brcm,bcm2835-spi", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
+
static int bcm2835_spi_probe(struct platform_device *pdev)
{
+ irq_handler_t bcm2835_spi_isr_func = bcm2835_spi_interrupt;
struct spi_controller *ctlr;
+ unsigned long flags = 0;
+ struct device_node *dn;
struct bcm2835_spi *bs;
int err;
+ /* On BCM2711 there can be multiple SPI controllers enabled sharing the
+ * same interrupt line, but we also want to minimize the overhead if
+ * there is no need to support interrupt sharing. If we find at least
+ * another available instane (not counting the one we are probed from),
+ * then we assume that interrupt sharing is necessary.
+ */
+ for_each_compatible_node(dn, NULL, bcm2835_spi_match[0].compatible) {
+ err = of_device_is_available(dn) && dn != pdev->dev.of_node;
+ of_node_put(dn);
+ if (err) {
+ flags = IRQF_SHARED;
+ bcm2835_spi_isr_func = bcm2835_spi_shared_interrupt;
+ break;
+ }
+ }
+
ctlr = spi_alloc_master(&pdev->dev, ALIGN(sizeof(*bs),
dma_get_cache_alignment()));
if (!ctlr)
@@ -1344,8 +1389,8 @@ static int bcm2835_spi_probe(struct platform_device *pdev)
bcm2835_wr(bs, BCM2835_SPI_CS,
BCM2835_SPI_CS_CLEAR_RX | BCM2835_SPI_CS_CLEAR_TX);
- err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_interrupt, 0,
- dev_name(&pdev->dev), ctlr);
+ err = devm_request_irq(&pdev->dev, bs->irq, bcm2835_spi_isr_func,
+ flags, dev_name(&pdev->dev), ctlr);
if (err) {
dev_err(&pdev->dev, "could not request IRQ: %d\n", err);
goto out_dma_release;
@@ -1400,12 +1445,6 @@ static void bcm2835_spi_shutdown(struct platform_device *pdev)
dev_err(&pdev->dev, "failed to shutdown\n");
}
-static const struct of_device_id bcm2835_spi_match[] = {
- { .compatible = "brcm,bcm2835-spi", },
- {}
-};
-MODULE_DEVICE_TABLE(of, bcm2835_spi_match);
-
static struct platform_driver bcm2835_spi_driver = {
.driver = {
.name = DRV_NAME,
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 1/1] perf: cs-etm: Allow no CoreSight sink to be specified on command line
From: Mathieu Poirier @ 2020-06-04 21:21 UTC (permalink / raw)
To: Mike Leach
Cc: suzuki.poulose, peterz, coresight, linux-kernel, acme, mingo,
linux-arm-kernel
In-Reply-To: <20200526105310.9706-2-mike.leach@linaro.org>
On Tue, May 26, 2020 at 11:53:10AM +0100, Mike Leach wrote:
> Adjust the handling of the session sink selection to allow no sink to
> be selected on the command line. This then forwards the sink selection to
> the CoreSight infrastructure which will attempt to select a sink based
> on the default sink select priorities.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> tools/perf/arch/arm/util/cs-etm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
> index 941f814820b8..ed9ea2c60f27 100644
> --- a/tools/perf/arch/arm/util/cs-etm.c
> +++ b/tools/perf/arch/arm/util/cs-etm.c
> @@ -242,10 +242,10 @@ static int cs_etm_set_sink_attr(struct perf_pmu *pmu,
> }
>
> /*
> - * No sink was provided on the command line - for _now_ treat
> - * this as an error.
> + * No sink was provided on the command line - allow the CoreSight
> + * system to look for a default
> */
> - return ret;
> + return 0;
Leo added a tested-by for this patch. As I wrote on a previous patch we are
currently in the middle of the merge window and as such this set needs to be
rebased on v5.8-rc1 (when it comes out) and sent again.
Thanks,
Mathieu
> }
>
> static int cs_etm_recording_options(struct auxtrace_record *itr,
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/5] coresight: etm: perf: Add default sink selection to etm perf
From: Mathieu Poirier @ 2020-06-04 21:18 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, acme, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20200526104642.9526-5-mike.leach@linaro.org>
On Tue, May 26, 2020 at 11:46:41AM +0100, Mike Leach wrote:
> Add default sink selection to the perf trace handling in the etm driver.
> Uses the select default sink infrastructure to select a sink for the perf
> session, if no other sink is specified.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> .../hwtracing/coresight/coresight-etm-perf.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 84f1dcb69827..1a3169e69bb1 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -226,9 +226,6 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
> sink = coresight_get_enabled_sink(true);
> }
>
> - if (!sink)
> - goto err;
> -
> mask = &event_data->mask;
>
> /*
> @@ -253,6 +250,16 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
> continue;
> }
>
> + /*
> + * No sink provided - look for a default sink for one of the
> + * devices. At present we only support topology where all CPUs
> + * use the same sink [N:1], so only need to find one sink. The
> + * coresight_build_path later will remove any CPU that does not
> + * attach to the sink, or if we have not found a sink.
> + */
> + if (!sink)
> + sink = coresight_find_default_sink(csdev);
> +
> /*
> * Building a path doesn't enable it, it simply builds a
> * list of devices from source to sink that can be
> @@ -267,6 +274,10 @@ static void *etm_setup_aux(struct perf_event *event, void **pages,
> *etm_event_cpu_path_ptr(event_data, cpu) = path;
> }
>
> + /* no sink found for any CPU - cannot trace */
> + if (!sink)
> + goto err;
> +
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> /* If we don't have any CPUs ready for tracing, abort */
> cpu = cpumask_first(mask);
> if (cpu >= nr_cpu_ids)
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/5] coresight: tmc: Update sink types for default selection.
From: Mathieu Poirier @ 2020-06-04 21:18 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, acme, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20200526104642.9526-4-mike.leach@linaro.org>
On Tue, May 26, 2020 at 11:46:40AM +0100, Mike Leach wrote:
> An additional sink subtype is added to differentiate ETB/ETF buffer
> sinks and ETR type system memory sinks.
>
> This allows the prioritised selection of default sinks.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> ---
> drivers/hwtracing/coresight/coresight-tmc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c
> index 39fba1d16e6e..0d2eb7e0e1bb 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc.c
> @@ -484,7 +484,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> break;
> case TMC_CONFIG_TYPE_ETR:
> desc.type = CORESIGHT_DEV_TYPE_SINK;
> - desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
> + desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM;
> desc.ops = &tmc_etr_cs_ops;
> ret = tmc_etr_setup_caps(dev, devid,
> coresight_get_uci_data(id));
> @@ -496,6 +496,7 @@ static int tmc_probe(struct amba_device *adev, const struct amba_id *id)
> break;
> case TMC_CONFIG_TYPE_ETF:
> desc.type = CORESIGHT_DEV_TYPE_LINKSINK;
> + desc.subtype.sink_subtype = CORESIGHT_DEV_SUBTYPE_SINK_BUFFER;
> desc.subtype.link_subtype = CORESIGHT_DEV_SUBTYPE_LINK_FIFO;
> desc.ops = &tmc_etf_cs_ops;
> dev_list = &etf_devs;
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 2/5] coresight: Add default sink selection to CoreSight base
From: Mathieu Poirier @ 2020-06-04 21:17 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, acme, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20200526104642.9526-3-mike.leach@linaro.org>
On Tue, May 26, 2020 at 11:46:39AM +0100, Mike Leach wrote:
> Adds a method to select a suitable sink connected to a given source.
>
> In cases where no sink is defined, the coresight_find_default_sink
> routine can search from a given source, through the child connections
> until a suitable sink is found.
>
> The suitability is defined in by the sink coresight_dev_subtype on the
> CoreSight device, and the distance from the source by counting
> connections.
>
> Higher value subtype is preferred - where these are equal, shorter
> distance from source is used as a tie-break.
>
> This allows for default sink to be discovered were none is specified
> (e.g. perf command line)
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Leo has also added a RB for this patch, please add it on when you rebase on
v5.8-rc1.
> ---
> drivers/hwtracing/coresight/coresight-priv.h | 2 +
> drivers/hwtracing/coresight/coresight.c | 136 +++++++++++++++++++
> include/linux/coresight.h | 3 +
> 3 files changed, 141 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-priv.h b/drivers/hwtracing/coresight/coresight-priv.h
> index 36c943ae94d5..f2dc625ea585 100644
> --- a/drivers/hwtracing/coresight/coresight-priv.h
> +++ b/drivers/hwtracing/coresight/coresight-priv.h
> @@ -150,6 +150,8 @@ int coresight_enable_path(struct list_head *path, u32 mode, void *sink_data);
> struct coresight_device *coresight_get_sink(struct list_head *path);
> struct coresight_device *coresight_get_enabled_sink(bool reset);
> struct coresight_device *coresight_get_sink_by_id(u32 id);
> +struct coresight_device *
> +coresight_find_default_sink(struct coresight_device *csdev);
> struct list_head *coresight_build_path(struct coresight_device *csdev,
> struct coresight_device *sink);
> void coresight_release_path(struct list_head *path);
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> index f3efbb3b2b4d..7632d060e25d 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight.c
> @@ -769,6 +769,142 @@ void coresight_release_path(struct list_head *path)
> path = NULL;
> }
>
> +/* return true if the device is a suitable type for a default sink */
> +static inline bool coresight_is_def_sink_type(struct coresight_device *csdev)
> +{
> + /* sink & correct subtype */
> + if (((csdev->type == CORESIGHT_DEV_TYPE_SINK) ||
> + (csdev->type == CORESIGHT_DEV_TYPE_LINKSINK)) &&
> + (csdev->subtype.sink_subtype >= CORESIGHT_DEV_SUBTYPE_SINK_BUFFER))
> + return true;
> + return false;
> +}
> +
> +/**
> + * coresight_select_best_sink - return the best sink for use as default from
> + * the two provided.
> + *
> + * @sink: current best sink.
> + * @depth: search depth where current sink was found.
> + * @new_sink: new sink for comparison with current sink.
> + * @new_depth: search depth where new sink was found.
> + *
> + * Sinks prioritised according to coresight_dev_subtype_sink, with only
> + * subtypes CORESIGHT_DEV_SUBTYPE_SINK_BUFFER or higher being used.
> + *
> + * Where two sinks of equal priority are found, the sink closest to the
> + * source is used (smallest search depth).
> + *
> + * return @new_sink & update @depth if better than @sink, else return @sink.
> + */
> +static struct coresight_device *
> +coresight_select_best_sink(struct coresight_device *sink, int *depth,
> + struct coresight_device *new_sink, int new_depth)
> +{
> + bool update = false;
> +
> + if (!sink) {
> + /* first found at this level */
> + update = true;
> + } else if (new_sink->subtype.sink_subtype >
> + sink->subtype.sink_subtype) {
> + /* found better sink */
> + update = true;
> + } else if ((new_sink->subtype.sink_subtype ==
> + sink->subtype.sink_subtype) &&
> + (*depth > new_depth)) {
> + /* found same but closer sink */
> + update = true;
> + }
> +
> + if (update)
> + *depth = new_depth;
> + return update ? new_sink : sink;
> +}
> +
> +/**
> + * coresight_find_sink - recursive function to walk trace connections from
> + * source to find a suitable default sink.
> + *
> + * @csdev: source / current device to check.
> + * @depth: [in] search depth of calling dev, [out] depth of found sink.
> + *
> + * This will walk the connection path from a source (ETM) till a suitable
> + * sink is encountered and return that sink to the original caller.
> + *
> + * If current device is a plain sink return that & depth, otherwise recursively
> + * call child connections looking for a sink. Select best possible using
> + * coresight_select_best_sink.
> + *
> + * return best sink found, or NULL if not found at this node or child nodes.
> + */
> +static struct coresight_device *
> +coresight_find_sink(struct coresight_device *csdev, int *depth)
> +{
> + int i, curr_depth = *depth + 1, found_depth = 0;
> + struct coresight_device *found_sink = NULL;
> +
> + if (coresight_is_def_sink_type(csdev)) {
> + found_depth = curr_depth;
> + found_sink = csdev;
> + if (csdev->type == CORESIGHT_DEV_TYPE_SINK)
> + goto return_def_sink;
> + /* look past LINKSINK for something better */
> + }
> +
> + /*
> + * Not a sink we want - or possible child sink may be better.
> + * recursively explore each port found on this element.
> + */
> + for (i = 0; i < csdev->pdata->nr_outport; i++) {
> + struct coresight_device *child_dev, *sink = NULL;
> + int child_depth = curr_depth;
> +
> + child_dev = csdev->pdata->conns[i].child_dev;
> + if (child_dev)
> + sink = coresight_find_sink(child_dev, &child_depth);
> +
> + if (sink)
> + found_sink = coresight_select_best_sink(found_sink,
> + &found_depth,
> + sink,
> + child_depth);
> + }
> +
> +return_def_sink:
> + /* return found sink and depth */
> + if (found_sink)
> + *depth = found_depth;
> + return found_sink;
> +}
> +
> +/**
> + * coresight_find_default_sink: Find a sink suitable for use as a
> + * default sink.
> + *
> + * @csdev: starting source to find a connected sink.
> + *
> + * Walks connections graph looking for a suitable sink to enable for the
> + * supplied source. Uses CoreSight device subtypes and distance from source
> + * to select the best sink.
> + *
> + * If a sink is found, then the default sink for this device is set and
> + * will be automatically used in future.
> + *
> + * Used in cases where the CoreSight user (perf / sysfs) has not selected a
> + * sink.
> + */
> +struct coresight_device *
> +coresight_find_default_sink(struct coresight_device *csdev)
> +{
> + int depth = 0;
> +
> + /* look for a default sink if we have not found for this device */
> + if (!csdev->def_sink)
> + csdev->def_sink = coresight_find_sink(csdev, &depth);
> + return csdev->def_sink;
> +}
> +
> /** coresight_validate_source - make sure a source has the right credentials
> * @csdev: the device structure for a source.
> * @function: the function this was called from.
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index 84dc695e87d4..58fffdecdbfd 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -48,6 +48,7 @@ enum coresight_dev_subtype_sink {
> CORESIGHT_DEV_SUBTYPE_SINK_NONE,
> CORESIGHT_DEV_SUBTYPE_SINK_PORT,
> CORESIGHT_DEV_SUBTYPE_SINK_BUFFER,
> + CORESIGHT_DEV_SUBTYPE_SINK_SYSMEM,
> };
>
> enum coresight_dev_subtype_link {
> @@ -182,6 +183,7 @@ struct coresight_sysfs_link {
> * happens when a source has been selected and a path is enabled
> * from source to that sink.
> * @ea: Device attribute for sink representation under PMU directory.
> + * @def_sink: cached reference to default sink found for this device.
> * @ect_dev: Associated cross trigger device. Not part of the trace data
> * path or connections.
> * @nr_links: number of sysfs links created to other components from this
> @@ -200,6 +202,7 @@ struct coresight_device {
> /* sink specific fields */
> bool activated; /* true only if a sink is part of a path */
> struct dev_ext_attribute *ea;
> + struct coresight_device *def_sink;
> /* cross trigger handling */
> struct coresight_device *ect_dev;
> /* sysfs links between components */
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/5] coresight: Fix comment in main header file.
From: Mathieu Poirier @ 2020-06-04 21:14 UTC (permalink / raw)
To: Mike Leach; +Cc: coresight, acme, linux-arm-kernel, suzuki.poulose
In-Reply-To: <20200526104642.9526-2-mike.leach@linaro.org>
On Tue, May 26, 2020 at 11:46:38AM +0100, Mike Leach wrote:
> Comment for an elemnt in the coresight_device structure appears to have
> been corrupted & makes no sense. Fix this before making further changes.
>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> include/linux/coresight.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index e3e9f0e3a878..84dc695e87d4 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -179,7 +179,8 @@ struct coresight_sysfs_link {
> * @enable: 'true' if component is currently part of an active path.
> * @activated: 'true' only if a _sink_ has been activated. A sink can be
> * activated but not yet enabled. Enabling for a _sink_
> - * appens when a source has been selected for that it.
> + * happens when a source has been selected and a path is enabled
> + * from source to that sink.
> * @ea: Device attribute for sink representation under PMU directory.
> * @ect_dev: Associated cross trigger device. Not part of the trace data
> * path or connections.
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 5/5] coresight: sysfs: Allow select default sink on source enable.
From: Mike Leach @ 2020-06-04 21:12 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Coresight ML, Arnaldo Carvalho de Melo, Mathieu Poirier,
linux-arm-kernel
In-Reply-To: <62411834-9273-e46c-dc34-71ae45013b96@arm.com>
HI Suzuki,
On Tue, 2 Jun 2020 at 12:46, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
> Hi Mike,
>
> On 05/26/2020 11:46 AM, Mike Leach wrote:
> > When enabling a trace source using sysfs, allow the CoreSight system to
> > auto-select a default sink if none has been enabled by the user.
> >
> > Uses the sink select algorithm that uses the default select priorities
> > set when sinks are registered with the system. At present this will
> > prefer ETR over ETB / ETF.
> >
> > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > ---
> > drivers/hwtracing/coresight/coresight.c | 11 +++++++++--
> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c
> > index 7632d060e25d..bd1a52a65d00 100644
> > --- a/drivers/hwtracing/coresight/coresight.c
> > +++ b/drivers/hwtracing/coresight/coresight.c
> > @@ -965,8 +965,15 @@ int coresight_enable(struct coresight_device *csdev)
> > */
> > sink = coresight_get_enabled_sink(false);
> > if (!sink) {
> > - ret = -EINVAL;
> > - goto out;
> > + /* look for a default sink if nothing enabled */
> > + sink = coresight_find_default_sink(csdev);
> > + if (!sink) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > + /* mark the default as enabled */
> > + sink->activated = true;
> > + dev_info(&sink->dev, "Enabled default sink.");
> > }
>
> To be honest, I would drop this change and mandate that the
> user enables the sink(s).
This is here to make it easy for users to explore CoreSight using
sysfs - which is what tends to happen when they first start using it.
Also useful for generic test scripts if no sink is needed to check if
the ETM is working.
> There is no way to reliably match
> which ETM is tracing to the sink above in case multiple ETMs
> are being enabled, even with the above message.
I can't imagine users setting multiple sinks, either through the
default route or the explicit set route. Either way the problem is the
same - which sink does the etm hit?
I think this means that we need to improve this rather than drop it.
The default sink could easily be read by from the ETM via sysfs. as
could an addition to provide a last used sink for sysfs.
This would be really useful in developing test scripts that exercised
ETMs on a system without having to figure out the sink used. Such
scripts would then be more portable.
Regards
Mike
>It is important
> for sysfs mode, as the user must collect the trace data manually,
> unlike the perf mode where the race data is collected and presented to
> the user via memory buffers.
>
> Suzuki
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 07/11] hwmon: add support for the sl28cpld hardware monitoring controller
From: Michael Walle @ 2020-06-04 21:10 UTC (permalink / raw)
To: linux-gpio, devicetree, linux-kernel, linux-hwmon, linux-pwm,
linux-watchdog, linux-arm-kernel
Cc: Marc Zyngier, Jean Delvare, Jason Cooper, Greg Kroah-Hartman,
Shawn Guo, Linus Walleij, Andy Shevchenko, Li Yang,
Bartosz Golaszewski, Michael Walle, Rob Herring, Thierry Reding,
Mark Brown, Uwe Kleine-König, Thomas Gleixner,
Wim Van Sebroeck, Lee Jones, Guenter Roeck
In-Reply-To: <20200604211039.12689-1-michael@walle.cc>
Add support for the hardware monitoring controller of the sl28cpld board
management controller. This driver is part of a multi-function device.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Guenter Roeck <linux@roeck-us.net>
---
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/sl28cpld.rst | 36 ++++++++
drivers/hwmon/Kconfig | 10 +++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/sl28cpld-hwmon.c | 150 +++++++++++++++++++++++++++++++
5 files changed, 198 insertions(+)
create mode 100644 Documentation/hwmon/sl28cpld.rst
create mode 100644 drivers/hwmon/sl28cpld-hwmon.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 55ff4b7c5349..1f4beb7449c7 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -153,6 +153,7 @@ Hardware Monitoring Kernel Drivers
sht3x
shtc1
sis5595
+ sl28cpld
smm665
smsc47b397
smsc47m192
diff --git a/Documentation/hwmon/sl28cpld.rst b/Documentation/hwmon/sl28cpld.rst
new file mode 100644
index 000000000000..7ed65f78250c
--- /dev/null
+++ b/Documentation/hwmon/sl28cpld.rst
@@ -0,0 +1,36 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Kernel driver sl28cpld
+======================
+
+Supported chips:
+
+ * Kontron sl28cpld
+
+ Prefix: 'sl28cpld'
+
+ Datasheet: not available
+
+Authors: Michael Walle <michael@walle.cc>
+
+Description
+-----------
+
+The sl28cpld is a board management controller which also exposes a hardware
+monitoring controller. At the moment this controller supports a single fan
+supervisor. In the future there might be other flavours and additional
+hardware monitoring might be supported.
+
+The fan supervisor has a 7 bit counter register and a counter period of 1
+second. If the 7 bit counter overflows, the supervisor will automatically
+switch to x8 mode to support a wider input range at the loss of
+granularity.
+
+Sysfs entries
+-------------
+
+The following attributes are supported.
+
+======================= ========================================================
+fan1_input Fan RPM. Assuming 2 pulses per revolution.
+======================= ========================================================
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 288ae9f63588..e1cab08e80ce 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1459,6 +1459,16 @@ config SENSORS_RASPBERRYPI_HWMON
This driver can also be built as a module. If so, the module
will be called raspberrypi-hwmon.
+config SENSORS_SL28CPLD
+ tristate "Kontron sl28cpl hardware monitoring driver"
+ depends on MFD_SL28CPLD
+ help
+ If you say yes here you get support for the fan supervisor of the
+ sl28cpld board management controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called sl28cpld-hwmon.
+
config SENSORS_SHT15
tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 3e32c21f5efe..03822f6bf970 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -158,6 +158,7 @@ obj-$(CONFIG_SENSORS_S3C) += s3c-hwmon.o
obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
obj-$(CONFIG_SENSORS_SCH5627) += sch5627.o
obj-$(CONFIG_SENSORS_SCH5636) += sch5636.o
+obj-$(CONFIG_SENSORS_SL28CPLD) += sl28cpld-hwmon.o
obj-$(CONFIG_SENSORS_SHT15) += sht15.o
obj-$(CONFIG_SENSORS_SHT21) += sht21.o
obj-$(CONFIG_SENSORS_SHT3x) += sht3x.o
diff --git a/drivers/hwmon/sl28cpld-hwmon.c b/drivers/hwmon/sl28cpld-hwmon.c
new file mode 100644
index 000000000000..de24964a7322
--- /dev/null
+++ b/drivers/hwmon/sl28cpld-hwmon.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * sl28cpld hardware monitoring driver.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include <linux/bitfield.h>
+#include <linux/hwmon.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#define FAN_INPUT 0x00
+#define FAN_SCALE_X8 BIT(7)
+#define FAN_VALUE_MASK GENMASK(6, 0)
+
+struct sl28cpld_hwmon {
+ struct regmap *regmap;
+ u32 offset;
+};
+
+static umode_t sl28cpld_hwmon_is_visible(const void *data,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ return 0444;
+}
+
+static int sl28cpld_hwmon_read(struct device *dev,
+ enum hwmon_sensor_types type, u32 attr,
+ int channel, long *input)
+{
+ struct sl28cpld_hwmon *hwmon = dev_get_drvdata(dev);
+ unsigned int value;
+ int ret;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ ret = regmap_read(hwmon->regmap, hwmon->offset + FAN_INPUT,
+ &value);
+ if (ret)
+ return ret;
+ /*
+ * The register has a 7 bit value and 1 bit which indicates the
+ * scale. If the MSB is set, then the lower 7 bit has to be
+ * multiplied by 8, to get the correct reading.
+ */
+ if (value & FAN_SCALE_X8)
+ value = FIELD_GET(FAN_VALUE_MASK, value) << 3;
+
+ /*
+ * The counter period is 1000ms and the sysfs specification
+ * says we should asssume 2 pulses per revolution.
+ */
+ value *= 60 / 2;
+
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ *input = value;
+ return 0;
+}
+
+static const u32 sl28cpld_hwmon_fan_config[] = {
+ HWMON_F_INPUT,
+ 0
+};
+
+static const struct hwmon_channel_info sl28cpld_hwmon_fan = {
+ .type = hwmon_fan,
+ .config = sl28cpld_hwmon_fan_config,
+};
+
+static const struct hwmon_channel_info *sl28cpld_hwmon_info[] = {
+ &sl28cpld_hwmon_fan,
+ NULL
+};
+
+static const struct hwmon_ops sl28cpld_hwmon_ops = {
+ .is_visible = sl28cpld_hwmon_is_visible,
+ .read = sl28cpld_hwmon_read,
+};
+
+static const struct hwmon_chip_info sl28cpld_hwmon_chip_info = {
+ .ops = &sl28cpld_hwmon_ops,
+ .info = sl28cpld_hwmon_info,
+};
+
+static int sl28cpld_hwmon_probe(struct platform_device *pdev)
+{
+ struct sl28cpld_hwmon *hwmon;
+ struct device *hwmon_dev;
+ int ret;
+
+ if (!pdev->dev.parent)
+ return -ENODEV;
+
+ hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
+ if (!hwmon)
+ return -ENOMEM;
+
+ hwmon->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!hwmon->regmap)
+ return -ENODEV;
+
+ ret = device_property_read_u32(&pdev->dev, "reg", &hwmon->offset);
+ if (ret)
+ return -EINVAL;
+
+ hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
+ "sl28cpld_hwmon", hwmon,
+ &sl28cpld_hwmon_chip_info, NULL);
+ if (IS_ERR(hwmon_dev)) {
+ dev_err(&pdev->dev, "failed to register as hwmon device");
+ return PTR_ERR(hwmon_dev);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sl28cpld_hwmon_of_match[] = {
+ { .compatible = "kontron,sl28cpld-fan" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sl28cpld_hwmon_of_match);
+
+static const struct platform_device_id sl28cpld_hwmon_id_table[] = {
+ { "sl28cpld-fan" },
+ {}
+};
+MODULE_DEVICE_TABLE(platform, sl28cpld_hwmon_id_table);
+
+static struct platform_driver sl28cpld_hwmon_driver = {
+ .probe = sl28cpld_hwmon_probe,
+ .id_table = sl28cpld_hwmon_id_table,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = sl28cpld_hwmon_of_match,
+ },
+};
+module_platform_driver(sl28cpld_hwmon_driver);
+
+MODULE_DESCRIPTION("sl28cpld Hardware Monitoring Driver");
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_LICENSE("GPL");
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox