* DT dtc warnings
From: Fabio Estevam @ 2017-12-14 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPfCDT+7wPkz3g6AiKgLvFp4rnicYQgYn8A_yaPe4YhD5A@mail.gmail.com>
On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Can anyone help why this W=1 triggers warning like these:
> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
> (simple_bus_reg): Node /soc/syscon-poweroff missing or empty
> reg/ranges property
> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
> (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges
> property
>
> For a node without unit address?
> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>
> AFAIR, if node does not have unit-address then it should not have
> reg/ranges property. Or maybe it is coming from parent's simple-bus?
syscon-poweroff and syscon-reboot should be outside the soc bus.
^ permalink raw reply
* DT dtc warnings
From: Krzysztof Kozlowski @ 2017-12-14 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BGX1U90bGrff42rZKKOSQK3NB=-k_4BX04Tsi=yX0Odg@mail.gmail.com>
On Thu, Dec 14, 2017 at 10:13 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Dec 14, 2017 at 7:01 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
>> Can anyone help why this W=1 triggers warning like these:
>> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
>> (simple_bus_reg): Node /soc/syscon-poweroff missing or empty
>> reg/ranges property
>> arch/arm/boot/dts/exynos3250-artik5-eval.dtb: Warning
>> (simple_bus_reg): Node /soc/syscon-reboot missing or empty reg/ranges
>> property
>>
>> For a node without unit address?
>> http://elixir.free-electrons.com/linux/v4.15-rc3/source/arch/arm/boot/dts/exynos-syscon-restart.dtsi
>>
>> AFAIR, if node does not have unit-address then it should not have
>> reg/ranges property. Or maybe it is coming from parent's simple-bus?
>
> syscon-poweroff and syscon-reboot should be outside the soc bus.
Thanks for reply!
Isn't this property of a SoC? The registers used by
syscon-poweroff/reboot are part of SoC power management unit. It does
not refer to any externals. Why then it should be put outside of soc?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: fix CONFIG_DEBUG_WX address reporting
From: Timur Tabi @ 2017-12-14 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <673df793-cc4c-b251-6846-7cba4931ff53@redhat.com>
On 12/14/2017 01:02 PM, Laura Abbott wrote:
>
> While we're fixing this up, do you want to drop the %p from the
> "Found insecure W+X" message from above since pointer hashing
> renders it kind of pointless or switch it to %px?
Switching to %px gives me:
arm64/mm: Found insecure W+X mapping at address
ffff2b1b4e512000/0xffff2b1b4e512000
Looks the same as before.
However, when I try to dump the contents of memory at that address via
print_hex_dump(), I get an "Unable to handle kernel paging request" oops.
[ 11.236091] Unable to handle kernel paging request at virtual address
ffff2b1b4e512000
[ 11.243985] pgd = ffff2b1b55a0d000
[ 11.247371] [ffff2b1b4e512000] *pgd=00000007ffffe003,
*pud=00000007ffffd003, *pmd=000000079972a003, *pte=0000000000000000
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Mauro Carvalho Chehab @ 2017-12-14 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214205706.GA1856@kroah.com>
Em Thu, 14 Dec 2017 21:57:06 +0100
Greg KH <gregkh@linuxfoundation.org> escreveu:
> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
> > Hi Greg,
> >
> > On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
> > > On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> > > > On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> > > >> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> > > >>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> > > >>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> > > >>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
> > wrote:
> > > >>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> > > >>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> > > >>>>>>> related drivers.
> > > >>>>>>>
> > > >>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> > > >>>>>>
> > > >>>>>> Hi Dhaval,
> > > >>>>>>
> > > >>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
> > > >>>>>> afraid that, without their explicit acks, sent to the ML, I can't
> > > >>>>>> accept a patch touching at the driver's license tags.
> > > >>>>>
> > > >>>>> The patch doesn't change the license, I don't see why it would cause
> > > >>>>> any issue. Greg isn't listed as the maintainer or copyright holder
> > > >>>>> of any of the 10k+ files to which he added an SPDX license header in
> > > >>>>> the last kernel release.
> > > >>>>
> > > >>>> Adding a comment line that describes an implicit or
> > > >>>> explicit license is different than removing the license
> > > >>>> text itself.
> > > >>>
> > > >>> The SPDX license header is meant to be equivalent to the license text.
> > > >>
> > > >> I understand that.
> > > >> At a minimum, removing BSD license text is undesirable
> > > >>
> > > >> as that license states:
> > > >> * * Redistributions of source code must retain the above copyright
> > > >> * notice, this list of conditions and the following disclaimer.
> > > >>
> > > >> etc...
> > > >
> > > > But this patch only removes the following text:
> > > >
> > > > - * This program is free software; you can redistribute it and/or modify
> > > > - * it under the terms of the GNU General Public License version 2 as
> > > > - * published by the Free Software Foundation.
> > > >
> > > > and replaces it by the corresponding SPDX header.
> > > >
> > > >>> The only reason why the large SPDX patch didn't touch the whole kernel
> > > >>> in one go was that it was easier to split in in multiple chunks.
> > > >>
> > > >> Not really, it was scripted.
> > > >
> > > > But still manually reviewed as far as I know.
> > > >
> > > >>> This is no different than not including the full GPL license in every
> > > >>> header file but only pointing to it through its name and reference, as
> > > >>> every kernel source file does.
> > > >>
> > > >> Not every kernel source file had a license text
> > > >> or a reference to another license file.
> > > >
> > > > Correct, but the files touched by this patch do.
> > > >
> > > > This issue is in no way specific to linux-media and should be decided upon
> > > > at the top level, not on a per-subsystem basis. Greg, could you comment
> > > > on this ?
> > >
> > > Comment on what exactly? I don't understand the problem here, care to
> > > summarize it?
> >
> > In a nutshell (if I understand it correctly), Dhaval Shah submitted https://
> > patchwork.kernel.org/patch/10102451/ which replaces
> >
> > +// SPDX-License-Identifier: GPL-2.0
> > [...]
> > - *
> > - * This program is free software; you can redistribute it and/or modify
> > - * it under the terms of the GNU General Public License version 2 as
> > - * published by the Free Software Foundation.
> >
> > in all .c and .h files of the Xilinx V4L2 driver (drivers/media/platform/
> > xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
> > stating that he can't accept a change to license text without an explicit ack
> > from the official driver's maintainers. My position is that such a change
> > doesn't change the license and thus doesn't need to track all copyright
> > holders, and can be merged without an explicit ack from the respective
> > maintainers.
>
> Yes, I agree with you, no license is being changed here, and no
> copyright is either.
>
> BUT, I know that most major companies are reviewing this process right
> now. We have gotten approval from almost all of the major kernel
> developer companies to do this, which is great, and supports this work
> as being acceptable.
>
> So it's nice to ask Xilinx if they object to this happening, which I
> guess Mauro is trying to say here (in not so many words...) To at least
> give them the heads-up that this is what is going to be going on
> throughout the kernel tree soon, and if they object, it would be good to
> speak up as to why (and if they do, I can put their lawyers in contact
> with some lawyers to explain it all to them.)
Yes, that's basically what I'm saying.
I don't feel comfortable on signing a patch changing the license text
without giving the copyright owners an opportunity and enough time
to review it and approve, or otherwise comment about such changes.
Thanks,
Mauro
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-14 22:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214194536.2269667d@recife.lan>
Hi Mauro,
On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
> > On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
> >> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
> >>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> >>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> >>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> >>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> >>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> >>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
> >>>>>>>> wrote:
> >>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> >>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> >>>>>>>>>> related drivers.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >>>>>>>>>
> >>>>>>>>> Hi Dhaval,
> >>>>>>>>>
> >>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
> >>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
> >>>>>>>>> can't accept a patch touching at the driver's license tags.
> >>>>>>>>
> >>>>>>>> The patch doesn't change the license, I don't see why it would
> >>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
> >>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
> >>>>>>>> header in the last kernel release.
> >>>>>>>
> >>>>>>> Adding a comment line that describes an implicit or
> >>>>>>> explicit license is different than removing the license
> >>>>>>> text itself.
> >>>>>>
> >>>>>> The SPDX license header is meant to be equivalent to the license
> >>>>>> text.
> >>>>>
> >>>>> I understand that.
> >>>>> At a minimum, removing BSD license text is undesirable
> >>>>>
> >>>>> as that license states:
> >>>>> * * Redistributions of source code must retain the above copyright
> >>>>> * notice, this list of conditions and the following disclaimer.
> >>>>>
> >>>>> etc...
> >>>>
> >>>> But this patch only removes the following text:
> >>>>
> >>>> - * This program is free software; you can redistribute it and/or
> >>>> modify
> >>>> - * it under the terms of the GNU General Public License version 2 as
> >>>> - * published by the Free Software Foundation.
> >>>>
> >>>> and replaces it by the corresponding SPDX header.
> >>>>
> >>>>>> The only reason why the large SPDX patch didn't touch the whole
> >>>>>> kernel in one go was that it was easier to split in in multiple
> >>>>>> chunks.
> >>>>>
> >>>>> Not really, it was scripted.
> >>>>
> >>>> But still manually reviewed as far as I know.
> >>>>
> >>>>>> This is no different than not including the full GPL license in
> >>>>>> every header file but only pointing to it through its name and
> >>>>>> reference, as every kernel source file does.
> >>>>>
> >>>>> Not every kernel source file had a license text
> >>>>> or a reference to another license file.
> >>>>
> >>>> Correct, but the files touched by this patch do.
> >>>>
> >>>> This issue is in no way specific to linux-media and should be
> >>>> decided upon at the top level, not on a per-subsystem basis. Greg,
> >>>> could you comment on this ?
> >>>
> >>> Comment on what exactly? I don't understand the problem here, care to
> >>> summarize it?
> >>
> >> In a nutshell (if I understand it correctly), Dhaval Shah submitted
> >> https:// patchwork.kernel.org/patch/10102451/ which replaces
> >>
> >> +// SPDX-License-Identifier: GPL-2.0
> >> [...]
> >> - *
> >> - * This program is free software; you can redistribute it and/or modify
> >> - * it under the terms of the GNU General Public License version 2 as
> >> - * published by the Free Software Foundation.
> >>
> >> in all .c and .h files of the Xilinx V4L2 driver
> >> (drivers/media/platform/
> >> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
> >> stating that he can't accept a change to license text without an
> >> explicit ack from the official driver's maintainers. My position is
> >> that such a change doesn't change the license and thus doesn't need to
> >> track all copyright holders, and can be merged without an explicit ack
> >> from the respective maintainers.
> >
> > Yes, I agree with you, no license is being changed here, and no
> > copyright is either.
> >
> > BUT, I know that most major companies are reviewing this process right
> > now. We have gotten approval from almost all of the major kernel
> > developer companies to do this, which is great, and supports this work
> > as being acceptable.
> >
> > So it's nice to ask Xilinx if they object to this happening, which I
> > guess Mauro is trying to say here (in not so many words...) To at least
> > give them the heads-up that this is what is going to be going on
> > throughout the kernel tree soon, and if they object, it would be good to
> > speak up as to why (and if they do, I can put their lawyers in contact
> > with some lawyers to explain it all to them.)
>
> Yes, that's basically what I'm saying.
>
> I don't feel comfortable on signing a patch changing the license text
> without giving the copyright owners an opportunity and enough time
> to review it and approve, or otherwise comment about such changes.
If I understand you and Greg correctly, you would like to get a general
approval from Xilinx for SPDX-related changes, but that would be a blanket
approval that would cover this and all subsequent similar patches. Is that
correct ? That is reasonable for me.
In that case, could the fact that commit
commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Nov 3 11:28:30 2017 +0100
USB: add SPDX identifiers to all remaining files in drivers/usb/
add SPDX headers to several Xilinx-authored source files constitute such a
blanket approval ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [RFC][PATCH] arm64: Switch to %px for printing some addresses at bootup
From: Laura Abbott @ 2017-12-14 22:39 UTC (permalink / raw)
To: linux-arm-kernel
With the move to stricter %p printing, several of the addresses
are no longer printed out. Switch to %px so they always get printed.
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
I'll admit to finding the new %p restrictions particularly irritating
here because I like seeing the print out of the virtual addresses for
debugging and checking. It might also be worth discussing whether we
should be printing anything out?
---
arch/arm64/mm/init.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5960bef0170d..9be53e050f50 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -613,15 +613,15 @@ void __init mem_init(void)
MLM(MODULES_VADDR, MODULES_END));
pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
MLG(VMALLOC_START, VMALLOC_END));
- pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .text : 0x%px" " - 0x%px" " (%6ld KB)\n",
MLK_ROUNDUP(_text, _etext));
- pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .rodata : 0x%px" " - 0x%px" " (%6ld KB)\n",
MLK_ROUNDUP(__start_rodata, __init_begin));
- pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .init : 0x%px" " - 0x%px" " (%6ld KB)\n",
MLK_ROUNDUP(__init_begin, __init_end));
- pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .data : 0x%px" " - 0x%px" " (%6ld KB)\n",
MLK_ROUNDUP(_sdata, _edata));
- pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
+ pr_notice(" .bss : 0x%px" " - 0x%px" " (%6ld KB)\n",
MLK_ROUNDUP(__bss_start, __bss_stop));
pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
MLK(FIXADDR_START, FIXADDR_TOP));
--
2.14.3
^ permalink raw reply related
* [PATCH v3 3/8] PCI: brcmstb: Add Broadcom STB PCIe host controller driver
From: Bjorn Helgaas @ 2017-12-14 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANCKTBvtqNWZYXpLdUnEWwA2=14XhJ6adR5muOAYubY_1SxZWw@mail.gmail.com>
On Wed, Dec 13, 2017 at 06:53:53PM -0500, Jim Quinlan wrote:
> On Tue, Dec 12, 2017 at 5:16 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Nov 14, 2017 at 05:12:07PM -0500, Jim Quinlan wrote:
> >> This commit adds the basic Broadcom STB PCIe controller. Missing is
> >> the ability to process MSI and also handle dma-ranges for inbound
> >> memory accesses. These two functionalities are added in subsequent
> >> commits.
> >>
> >> The PCIe block contains an MDIO interface. This is a local interface
> >> only accessible by the PCIe controller. It cannot be used or shared
> >> by any other HW. As such, the small amount of code for this
> >> controller is included in this driver as there is little upside to put
> >> it elsewhere.
> ...
> >> +static bool brcm_pcie_valid_device(struct brcm_pcie *pcie, struct pci_bus *bus,
> >> + int dev)
> >> +{
> >> + if (pci_is_root_bus(bus)) {
> >> + if (dev > 0)
> >> + return false;
> >> + } else {
> >> + /* If there is no link, then there is no device */
> >> + if (!brcm_pcie_link_up(pcie))
> >> + return false;
> >
> > This is racy, since the link can go down after you check but before
> > you do the config access. I assume your hardware can deal with a
> > config access that targets a link that is down?
>
> Yes, that can happen but there is really nothing that can be done if
> the link goes down in that vulnerability window. What do you suggest
> doing?
Most hardware drops writes and returns ~0 on reads if the link is
down. I assume your hardware does something similar, and that should
be enough. You shouldn't have to check whether the link is up.
The hardware might report errors, e.g., via AER, if the link is down.
And we might not not handle those nicely. If we have issues there, we
should find out and fix them.
I see that dwc, altera, rockchip, and xilinx all do check for link up
there, too. I can't remember if they had a legitimate reason, or if I
just missed it.
> >> +static void brcm_pcie_remove_controller(struct brcm_pcie *pcie)
> >> +{
> >> + struct list_head *pos, *q;
> >> + struct brcm_pcie *tmp;
> >> +
> >> + mutex_lock(&brcm_pcie_lock);
> >> + list_for_each_safe(pos, q, &brcm_pcie) {
> >> + tmp = list_entry(pos, struct brcm_pcie, list);
> >> + if (tmp == pcie) {
> >> + list_del(pos);
> >> + if (list_empty(&brcm_pcie))
> >> + num_memc = 0;
> >> + break;
> >> + }
> >> + }
> >> + mutex_unlock(&brcm_pcie_lock);
> >
> > I'm missing something. I don't see that num_memc is ever set to
> > anything *other* than zero.
> The num_memc is set and used in the dma commit. I will remove its
> declaration from this commit.
Thanks, that will make the patches much easier to read.
> >> + pcie->id = of_get_pci_domain_nr(dn);
> >
> > Why do you call of_get_pci_domain_nr() directly? No other driver
> > does.
>
> We use the domain as the controller number (id). We use the id to
> identify and fix a HW bug that only affects the 2nd controller; see
> the clause
> " } else if (of_machine_is_compatible("brcm,bcm7278a0")) {".
pci_register_host_bridge() already sets bus->domain_nr for every host
bridge. That path calls of_get_pci_domain_nr() eventually. But I
guess that's too late for your use case, because you have this:
brcm_pcie_probe
brcm_pcie_setup
brcm_pcie_bridge_sw_init_set
if (of_machine_is_compatible("brcm,bcm7278a0")) {
offset = pcie->id ? ... <--- use
pci_scan_root_bus_bridge
pci_register_host_bridge
bus->domain_nr = pci_bus_find_domain_nr <--- available
I guess you haven't added a binding for brcm,bcm7278a0 yet?
I'm not really sure that using the linux,pci-domain DT property is the
best way to distinguish the two controllers. Maybe Rob has an
opinion?
> >> + if (pcie->id < 0)
> >> + return pcie->id;
Bjorn
^ permalink raw reply
* [RFC][PATCH] arm64: Switch to %px for printing some addresses at bootup
From: Kees Cook @ 2017-12-14 22:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214223914.12532-1-labbott@redhat.com>
On Thu, Dec 14, 2017 at 2:39 PM, Laura Abbott <labbott@redhat.com> wrote:
> With the move to stricter %p printing, several of the addresses
> are no longer printed out. Switch to %px so they always get printed.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> I'll admit to finding the new %p restrictions particularly irritating
> here because I like seeing the print out of the virtual addresses for
> debugging and checking. It might also be worth discussing whether we
> should be printing anything out?
If they're always printed at boot, I think they should likely be removed...
-Kees
> ---
> arch/arm64/mm/init.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 5960bef0170d..9be53e050f50 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -613,15 +613,15 @@ void __init mem_init(void)
> MLM(MODULES_VADDR, MODULES_END));
> pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
> MLG(VMALLOC_START, VMALLOC_END));
> - pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
> + pr_notice(" .text : 0x%px" " - 0x%px" " (%6ld KB)\n",
> MLK_ROUNDUP(_text, _etext));
> - pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
> + pr_notice(" .rodata : 0x%px" " - 0x%px" " (%6ld KB)\n",
> MLK_ROUNDUP(__start_rodata, __init_begin));
> - pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
> + pr_notice(" .init : 0x%px" " - 0x%px" " (%6ld KB)\n",
> MLK_ROUNDUP(__init_begin, __init_end));
> - pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
> + pr_notice(" .data : 0x%px" " - 0x%px" " (%6ld KB)\n",
> MLK_ROUNDUP(_sdata, _edata));
> - pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
> + pr_notice(" .bss : 0x%px" " - 0x%px" " (%6ld KB)\n",
> MLK_ROUNDUP(__bss_start, __bss_stop));
> pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
> MLK(FIXADDR_START, FIXADDR_TOP));
> --
> 2.14.3
>
--
Kees Cook
Pixel Security
^ permalink raw reply
* DT dtc warnings
From: Fabio Estevam @ 2017-12-14 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPea5nx+i+vWJcMGqct1=gP5OHbDSAzqTCBYr1RvFW-1gw@mail.gmail.com>
On Thu, Dec 14, 2017 at 7:19 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Thanks for reply!
>
> Isn't this property of a SoC? The registers used by
> syscon-poweroff/reboot are part of SoC power management unit. It does
> not refer to any externals. Why then it should be put outside of soc?
If these nodes have registers, then they should have a unit address
and reg property.
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH net-next v6 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Florian Fainelli @ 2017-12-14 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513245910-15961-2-git-send-email-hayashi.kunihiko@socionext.com>
On 12/14/2017 02:05 AM, Kunihiko Hayashi wrote:
> DT bindings for the AVE ethernet controller found on Socionext's
> UniPhier platforms.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/net/socionext,uniphier-ave4.txt | 48 ++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
>
> diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> new file mode 100644
> index 0000000..4700377
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
> @@ -0,0 +1,48 @@
> +* Socionext AVE ethernet controller
> +
> +This describes the devicetree bindings for AVE ethernet controller
> +implemented on Socionext UniPhier SoCs.
> +
> +Required properties:
> + - compatible: Should be
> + - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
> + - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
> + - "socionext,uniphier-ld11-ave4" : for LD11 SoC
> + - "socionext,uniphier-ld20-ave4" : for LD20 SoC
> + - reg: Address where registers are mapped and size of region.
> + - interrupts: Should contain the MAC interrupt.
> + - phy-mode: See ethernet.txt in the same directory. Allow to choose
> + "rgmii", "rmii", or "mii" according to the PHY.
> + - phy-handle: Should point to the external phy device.
> + See ethernet.txt file in the same directory.
> + - clocks: A phandle to the clock for the MAC.
> +
> +Optional properties:
> + - resets: A phandle to the reset control for the MAC
> + - local-mac-address: See ethernet.txt in the same directory.
> +
> +Required subnode:
> + - mdio: Device tree subnode with the following required properties:
> + - #address-cells: Must be <1>.
> + - #size-cells: Must be <0>.
> + - reg: phy ID number, usually a small integer.
Almost, the "reg" property applies to the MDIO child nodes: the Ethernet
PHYs/MDIO devices. For the MDIO controller itself, the "reg" property,
if specified, would be relative to the Ethernet controller's base
register address.
Please drop this property's description here.
> +
> +Example:
> +
> + ether: ethernet at 65000000 {
> + compatible = "socionext,uniphier-ld20-ave4";
> + reg = <0x65000000 0x8500>;
> + interrupts = <0 66 4>;
> + phy-mode = "rgmii";
> + phy-handle = <ðphy>;
> + clocks = <&sys_clk 6>;
> + resets = <&sys_rst 6>;
> + local-mac-address = [00 00 00 00 00 00];
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ethphy: ethphy at 1 {
> + reg = <1>;
> + };
> + };
> + };
>
--
Florian
^ permalink raw reply
* [RFC][PATCH] arm64: Switch to %px for printing some addresses at bootup
From: Laura Abbott @ 2017-12-14 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jK1H1+VSENq9uVGJsqOkB42WvZuRviyPpSmgywUmXte8A@mail.gmail.com>
On 12/14/2017 02:51 PM, Kees Cook wrote:
> On Thu, Dec 14, 2017 at 2:39 PM, Laura Abbott <labbott@redhat.com> wrote:
>> With the move to stricter %p printing, several of the addresses
>> are no longer printed out. Switch to %px so they always get printed.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> I'll admit to finding the new %p restrictions particularly irritating
>> here because I like seeing the print out of the virtual addresses for
>> debugging and checking. It might also be worth discussing whether we
>> should be printing anything out?
>
> If they're always printed at boot, I think they should likely be removed...
>
> -Kees
>
Yeah, I suspected as much. I'll submit a patch to just remove it
unless someone has a counter proposal.
Thanks,
Laura
>> ---
>> arch/arm64/mm/init.c | 10 +++++-----
>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 5960bef0170d..9be53e050f50 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -613,15 +613,15 @@ void __init mem_init(void)
>> MLM(MODULES_VADDR, MODULES_END));
>> pr_notice(" vmalloc : 0x%16lx - 0x%16lx (%6ld GB)\n",
>> MLG(VMALLOC_START, VMALLOC_END));
>> - pr_notice(" .text : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .text : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(_text, _etext));
>> - pr_notice(" .rodata : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .rodata : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__start_rodata, __init_begin));
>> - pr_notice(" .init : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .init : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__init_begin, __init_end));
>> - pr_notice(" .data : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .data : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(_sdata, _edata));
>> - pr_notice(" .bss : 0x%p" " - 0x%p" " (%6ld KB)\n",
>> + pr_notice(" .bss : 0x%px" " - 0x%px" " (%6ld KB)\n",
>> MLK_ROUNDUP(__bss_start, __bss_stop));
>> pr_notice(" fixed : 0x%16lx - 0x%16lx (%6ld KB)\n",
>> MLK(FIXADDR_START, FIXADDR_TOP));
>> --
>> 2.14.3
>>
>
>
>
^ permalink raw reply
* [PATCH] perf probe arm64: Fix symbol fixup issues due to ELF type
From: Kim Phillips @ 2017-12-14 23:52 UTC (permalink / raw)
To: linux-arm-kernel
On an arm64 machine running a CONFIG_RANDOMIZE_BASE=y kernel, perf
kernel symbol resolution fails. Debugging saw symsrc_init calling the
default elf__needs_adjust_symbols() where checks for an ET_DYN (3)
ehdr.e_type failed when they should have succeeded.
Fix by adopting powerpc version of the weak elf__needs_adjust_symbols()
function, as done in commit d2332098331f ("perf probe ppc: Fix symbol
fixup issues due to ELF type").
Prior to this patch, perf test 1 would fail:
$ sudo oldperf test -v 1 |& head
1: vmlinux symtab matches kallsyms :
test child forked, pid 33374
Looking at the vmlinux_path (8 entries long)
Using /usr/lib/debug/boot/vmlinux for symbols
ERR : 0xfffe0000100f1000: do_undefinstr not on kallsyms
ERR : 0xfffe0000100f1320: do_sysinstr not on kallsyms
ERR : 0xfffe0000100f13b0: do_debug_exception not on kallsyms
ERR : 0xfffe0000100f1498: do_mem_abort not on kallsyms
ERR : 0xfffe0000100f1580: do_sp_pc_abort not on kallsyms
...
After applying this patch, perf test 1 now succeeds:
$ sudo ./newperf test -v 1 |& head
1: vmlinux symtab matches kallsyms :
test child forked, pid 33378
Looking at the vmlinux_path (8 entries long)
Using /usr/lib/debug/boot/vmlinux for symbols
WARN: 0xffff000008081000: diff name v: do_undefinstr k:
__exception_text_start
WARN: 0xffff0000080819e8: diff name v: __irqentry_text_end k:
__softirqentry_text_start
WARN: 0xffff000008081d08: diff name v: __entry_text_start k:
__softirqentry_text_end
WARN: 0xffff00000809db5c: diff name v: flush_icache_range k:
__flush_cache_user_range
WARN: 0xffff000008101908: diff name v: sys_ni_syscall k: sys_vm86old
...
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
---
tools/perf/arch/arm64/util/Build | 1 +
tools/perf/arch/arm64/util/sym-handling.c | 22 ++++++++++++++++++++++
2 files changed, 23 insertions(+)
create mode 100644 tools/perf/arch/arm64/util/sym-handling.c
diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
index b1ab72d2a42e..e04f6cdd6f32 100644
--- a/tools/perf/arch/arm64/util/Build
+++ b/tools/perf/arch/arm64/util/Build
@@ -1,4 +1,5 @@
libperf-y += header.o
+libperf-y += sym-handling.o
libperf-$(CONFIG_DWARF) += dwarf-regs.o
libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
diff --git a/tools/perf/arch/arm64/util/sym-handling.c b/tools/perf/arch/arm64/util/sym-handling.c
new file mode 100644
index 000000000000..0051b1ee8450
--- /dev/null
+++ b/tools/perf/arch/arm64/util/sym-handling.c
@@ -0,0 +1,22 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * Copyright (C) 2015 Naveen N. Rao, IBM Corporation
+ */
+
+#include "debug.h"
+#include "symbol.h"
+#include "map.h"
+#include "probe-event.h"
+#include "probe-file.h"
+
+#ifdef HAVE_LIBELF_SUPPORT
+bool elf__needs_adjust_symbols(GElf_Ehdr ehdr)
+{
+ return ehdr.e_type == ET_EXEC ||
+ ehdr.e_type == ET_REL ||
+ ehdr.e_type == ET_DYN;
+}
+#endif
--
2.15.1
^ permalink raw reply related
* [patch v14 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2017-12-15 1:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513268971-13518-3-git-send-email-oleksandrs@mellanox.com>
On Fri, Dec 15, 2017 at 2:59 AM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
Looks good. I have a few small things below, but I am happy to see
this merged from my point of view as ASPEED maintainer.
Cheers,
Joel
> +
> +menuconfig JTAG_ASPEED
> + tristate "Aspeed SoC JTAG controller support"
> + depends on JTAG && HAS_IOMEM
Add ARCH_ASPEED || COMPILE_TEST
> + ---help---
> + This provides a support for Aspeed JTAG device, equipped on
> + Aspeed SoC 24xx and 25xx families. Drivers allows programming
> + of hardware devices, connected to SoC through the JTAG interface.
> +
> + If you want this support, you should say Y here.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called jtag-aspeed.
> diff --git a/drivers/jtag/Makefile b/drivers/jtag/Makefile
> index af37493..04a855e 100644
> --- a/drivers/jtag/Makefile
> +++ b/drivers/jtag/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_JTAG) += jtag.o
> +obj-$(CONFIG_JTAG_ASPEED) += jtag-aspeed.o
> diff --git a/drivers/jtag/jtag-aspeed.c b/drivers/jtag/jtag-aspeed.c
> new file mode 100644
> index 0000000..99277d2
> --- /dev/null
> +++ b/drivers/jtag/jtag-aspeed.c
> @@ -0,0 +1,783 @@
> +static int aspeed_jtag_xfer(struct jtag *jtag, struct jtag_xfer *xfer,
> + u8 *xfer_data)
> +{
> + static const u8 sm_update_shiftir[] = {1, 1, 0, 0};
> + static const u8 sm_update_shiftdr[] = {1, 0, 0};
> + static const u8 sm_pause_idle[] = {1, 1, 0};
> + static const u8 sm_pause_update[] = {1, 1};
> + struct aspeed_jtag *aspeed_jtag = jtag_priv(jtag);
> + unsigned long *data = (unsigned long *)xfer_data;
> + unsigned long remain_xfer = xfer->length;
> + unsigned long offset;
> + char dbg_str[256];
> + int pos = 0;
> + int i;
> +
> + for (offset = 0, i = 0; offset < xfer->length;
> + offset += ASPEED_JTAG_DATA_CHUNK_SIZE, i++) {
It looks like offset is unused.
> + pos += snprintf(&dbg_str[pos], sizeof(dbg_str) - pos,
> + "0x%08lx ", data[i]);
> + }
> +
> + dev_dbg(aspeed_jtag->dev, "aspeed_jtag %s %s xfer, mode:%s, END:%d, len:%lu, TDI[%s]\n",
> + xfer->type == JTAG_SIR_XFER ? "SIR" : "SDR",
> + xfer->direction == JTAG_READ_XFER ? "READ" : "WRITE",
> + aspeed_jtag->mode & JTAG_XFER_HW_MODE ? "HW" : "SW",
> + xfer->endstate, remain_xfer, dbg_str);
> +
> + if (!(aspeed_jtag->mode & JTAG_XFER_HW_MODE)) {
> + /* SW mode */
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> +
> + if (aspeed_jtag->status != JTAG_STATE_IDLE) {
> + /*IR/DR Pause->Exit2 IR / DR->Update IR /DR */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_pause_update,
> + sizeof(sm_pause_update));
> + }
> +
> + if (xfer->type == JTAG_SIR_XFER)
> + /* ->IRSCan->CapIR->ShiftIR */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_update_shiftir,
> + sizeof(sm_update_shiftir));
> + else
> + /* ->DRScan->DRCap->DRShift */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_update_shiftdr,
> + sizeof(sm_update_shiftdr));
> +
> + aspeed_jtag_xfer_sw(aspeed_jtag, xfer, data);
> +
> + /* DIPause/DRPause */
> + aspeed_jtag_tck_cycle(aspeed_jtag, 0, 0);
> +
> + if (xfer->endstate == JTAG_STATE_IDLE) {
> + /* ->DRExit2->DRUpdate->IDLE */
> + aspeed_jtag_sm_cycle(aspeed_jtag, sm_pause_idle,
> + sizeof(sm_pause_idle));
> + }
> + } else {
> + /* hw mode */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_SW);
> + aspeed_jtag_xfer_hw(aspeed_jtag, xfer, data);
> + }
> +
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> + aspeed_jtag->status = xfer->endstate;
> + return 0;
> +}
>
> +
> +static irqreturn_t aspeed_jtag_interrupt(s32 this_irq, void *dev_id)
> +{
> + struct aspeed_jtag *aspeed_jtag = dev_id;
> + irqreturn_t ret;
> + u32 status;
> +
> + status = aspeed_jtag_read(aspeed_jtag, ASPEED_JTAG_ISR);
> + dev_dbg(aspeed_jtag->dev, "status %x\n", status);
> +
> + if (status & ASPEED_JTAG_ISR_INT_MASK) {
> + aspeed_jtag_write(aspeed_jtag,
> + (status & ASPEED_JTAG_ISR_INT_MASK)
> + | (status & ASPEED_JTAG_ISR_INT_EN_MASK),
> + ASPEED_JTAG_ISR);
> + aspeed_jtag->flag |= status & ASPEED_JTAG_ISR_INT_MASK;
> + }
> +
> + if (aspeed_jtag->flag) {
> + wake_up_interruptible(&aspeed_jtag->jtag_wq);
> + ret = IRQ_HANDLED;
> + } else {
> + dev_err(aspeed_jtag->dev, "aspeed_jtag irq status:%x\n",
using dev_err will give you sensible prefixes for any messages that
print out. You could remove "aspeed_jtag" from this any any other
prints you have.
> + status);
> + ret = IRQ_NONE;
> + }
> + return ret;
> +}
> +
> +int aspeed_jtag_init(struct platform_device *pdev,
> + struct aspeed_jtag *aspeed_jtag)
> +{
> + struct resource *res;
> + int err;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + aspeed_jtag->reg_base = devm_ioremap_resource(aspeed_jtag->dev, res);
> + if (IS_ERR(aspeed_jtag->reg_base))
> + return -ENOMEM;
> +
> + aspeed_jtag->pclk = devm_clk_get(aspeed_jtag->dev, NULL);
> + if (IS_ERR(aspeed_jtag->pclk)) {
> + dev_err(aspeed_jtag->dev, "devm_clk_get failed\n");
> + return PTR_ERR(aspeed_jtag->pclk);
> + }
> +
> + clk_prepare_enable(aspeed_jtag->pclk);
Can you move this below the platform_get_irq? that way you can return
an error if the getting the IRQ fails, without having to clean up the
clock.
> +
> + aspeed_jtag->irq = platform_get_irq(pdev, 0);
> + if (aspeed_jtag->irq < 0) {
> + dev_err(aspeed_jtag->dev, "no irq specified\n");
> + err = -ENOENT;
> + goto clk_unprep;
> + }
> +
> + /* Enable clock */
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_CTL_ENG_EN |
> + ASPEED_JTAG_CTL_ENG_OUT_EN, ASPEED_JTAG_CTRL);
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_SW_MODE_EN |
> + ASPEED_JTAG_SW_MODE_TDIO, ASPEED_JTAG_SW);
> +
> + err = devm_request_irq(aspeed_jtag->dev, aspeed_jtag->irq,
> + aspeed_jtag_interrupt, 0,
> + "aspeed-jtag", aspeed_jtag);
> + if (err) {
> + dev_err(aspeed_jtag->dev, "aspeed_jtag unable to get IRQ");
> + goto clk_unprep;
> + }
> + dev_dbg(&pdev->dev, "aspeed_jtag:IRQ %d.\n", aspeed_jtag->irq);
Again, remove the aspeed_jtag prefix.
> +
> + aspeed_jtag_write(aspeed_jtag, ASPEED_JTAG_ISR_INST_PAUSE |
> + ASPEED_JTAG_ISR_INST_COMPLETE |
> + ASPEED_JTAG_ISR_DATA_PAUSE |
> + ASPEED_JTAG_ISR_DATA_COMPLETE |
> + ASPEED_JTAG_ISR_INST_PAUSE_EN |
> + ASPEED_JTAG_ISR_INST_COMPLETE_EN |
> + ASPEED_JTAG_ISR_DATA_PAUSE_EN |
> + ASPEED_JTAG_ISR_DATA_COMPLETE_EN,
> + ASPEED_JTAG_ISR);
> +
> + aspeed_jtag->flag = 0;
> + aspeed_jtag->mode = 0;
> + init_waitqueue_head(&aspeed_jtag->jtag_wq);
> + return 0;
> +
> +clk_unprep:
> + clk_disable_unprepare(aspeed_jtag->pclk);
> + return err;
> +}
> +
> +int aspeed_jtag_deinit(struct platform_device *pdev,
> + struct aspeed_jtag *aspeed_jtag)
> +{
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_ISR);
> + /* Disable clock */
> + aspeed_jtag_write(aspeed_jtag, 0, ASPEED_JTAG_CTRL);
> + clk_disable_unprepare(aspeed_jtag->pclk);
> + return 0;
> +}
> +
> +static const struct jtag_ops aspeed_jtag_ops = {
> + .freq_get = aspeed_jtag_freq_get,
> + .freq_set = aspeed_jtag_freq_set,
> + .status_get = aspeed_jtag_status_get,
> + .idle = aspeed_jtag_idle,
> + .xfer = aspeed_jtag_xfer,
> + .mode_set = aspeed_jtag_mode_set
> +};
> +
> +static int aspeed_jtag_probe(struct platform_device *pdev)
> +{
> + struct aspeed_jtag *aspeed_jtag;
> + struct device *dev;
> + struct jtag *jtag;
> + int err;
> +
> + dev = &pdev->dev;
> + if (!of_device_is_compatible(pdev->dev.of_node,
> + "aspeed,ast2500-jtag") &&
> + !of_device_is_compatible(pdev->dev.of_node,
> + "aspeed,ast2400-jtag"))
> + return -ENODEV;
Given the Aspeed device only ever probes with device tree, can you
drop these redundant checks?
> +
> + jtag = jtag_alloc(sizeof(*aspeed_jtag), &aspeed_jtag_ops);
> + if (!jtag)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, jtag);
> + aspeed_jtag = jtag_priv(jtag);
> + aspeed_jtag->dev = &pdev->dev;
> +
> + /* Initialize device*/
> + err = aspeed_jtag_init(pdev, aspeed_jtag);
> + if (err)
> + goto err_jtag_init;
> +
> + /* Initialize JTAG core structure*/
> + err = jtag_register(jtag);
> + if (err)
> + goto err_jtag_register;
> +
> + return 0;
> +
> +err_jtag_register:
> + aspeed_jtag_deinit(pdev, aspeed_jtag);
> +err_jtag_init:
> + jtag_free(jtag);
> + return err;
> +}
> +
> +static int aspeed_jtag_remove(struct platform_device *pdev)
> +{
> + struct jtag *jtag;
> +
> + jtag = platform_get_drvdata(pdev);
> + aspeed_jtag_deinit(pdev, jtag_priv(jtag));
> + jtag_unregister(jtag);
> + jtag_free(jtag);
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_jtag_of_match[] = {
> + { .compatible = "aspeed,ast2400-jtag", },
> + { .compatible = "aspeed,ast2500-jtag", },
> + {}
> +};
> +
> +static struct platform_driver aspeed_jtag_driver = {
> + .probe = aspeed_jtag_probe,
> + .remove = aspeed_jtag_remove,
> + .driver = {
> + .name = ASPEED_JTAG_NAME,
> + .of_match_table = aspeed_jtag_of_match,
> + },
> +};
> +module_platform_driver(aspeed_jtag_driver);
> +
> +MODULE_AUTHOR("Oleksandr Shamray <oleksandrs@mellanox.com>");
> +MODULE_DESCRIPTION("ASPEED JTAG driver");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.1
>
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-15 1:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513269947.2261.9.camel@baylibre.com>
Hi Jerome:
On 12/15/17 00:45, Jerome Brunet wrote:
> On Thu, 2017-12-14 at 11:02 +0800, Yixun Lan wrote:
>> ---
>> Changes in v2 since [1]:
>> - rebase to kevin's v4.16/dt64 branch
>> - add Neil's Reviewed-by
>> - move clock info to board.dts instead of in soc.dtsi
>
> You got this comment regarding the pwm clock setup. the setup of the pwm clocks
> depends on the use case, so should defined depending on the requirement on the
> board
>
Yes, I thought it was a convention to put the clock into board.dts ..
I think it's more clear if you could have a three level hierarchy:
arch.dtsi. soc.dtsi, board.dts
most of clock and pinctrl could go to soc.dtsi
> This is not the case for the ethmac, the clock setup will be same for every
> board, unless I missed something. the clock bindings should be defined in
> meson-axg.dtsi, I think
>
yes, clock should be same
I will send another series to fix this
also will fold the DT separation (for soc.dtsi vs board.dts)
>> - drop "meson-axg-dwmac" compatible string, since we didn't use this
>> we could re-add it later when we really need.
>> - note: to make ethernet work properly,it depend on clock & pinctrl[2],
>> to compile the DTS, the patch [3] is required.
>> the code part will be taken via clock & pinctrl subsystem tree.
>
> .
>
^ permalink raw reply
* [PATCH v7 6/6] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: Yixun Lan @ 2017-12-15 1:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513270051.2261.11.camel@baylibre.com>
On 12/15/17 00:47, Jerome Brunet wrote:
> On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote:
>> Switch the uart_ao pclk to CLK81 since the clock driver is ready.
>> Also move the clock info to the board.dts instead in the soc.dtsi.
>
> Same comment as for ethmac, is it really wise ?
> Isn't the clock setup the same for the axg family ?
>
HI Jerome:
yes, should be same for AXG family
HI Kevin:
could you take the patch [5/6]? then I just need to resend for this one
Yixun
^ permalink raw reply
* [PATCH v3 0/2] Add ethernet support for Meson-AXG SoC
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.
Changes in v3 since [4]:
- put clock DT info in soc.dtsi
- separate DT for 'add support for the controller' vs 'enable in board'
Changes in v2 since [1]:
- rebase to kevin's v4.16/dt64 branch
- add Neil's Reviewed-by
- move clock info to board.dts instead of in soc.dtsi
- drop "meson-axg-dwmac" compatible string, since we didn't use this
we could re-add it later when we really need.
- note: to make ethernet work properly,it depend on clock & pinctrl[2],
to compile the DTS, the patch [3] is required.
the code part will be taken via clock & pinctrl subsystem tree.
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
Yixun Lan (2):
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
--
2.15.1
^ permalink raw reply
* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-1-yixun.lan@amlogic.com>
Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d356ce74ad89..94c4972222b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -148,6 +149,19 @@
#address-cells = <0>;
};
+ ethmac: ethernet at ff3f0000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0x0 0xff3f0000 0x0 0x10000
+ 0x0 0xff634540 0x0 0x8>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "macirq";
+ clocks = <&clkc CLKID_ETH>,
+ <&clkc CLKID_FCLK_DIV2>,
+ <&clkc CLKID_MPLL2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ status = "disabled";
+ };
+
hiubus: bus at ff63c000 {
compatible = "simple-bus";
reg = <0x0 0xff63c000 0x0 0x1c00>;
@@ -194,6 +208,46 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ eth_rgmii_x_pins: eth-x-rgmii {
+ mux {
+ groups = "eth_mdio_x",
+ "eth_mdc_x",
+ "eth_rgmii_rx_clk_x",
+ "eth_rx_dv_x",
+ "eth_rxd0_x",
+ "eth_rxd1_x",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_x",
+ "eth_txd0_x",
+ "eth_txd1_x",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
+ eth_rgmii_y_pins: eth-y-rgmii {
+ mux {
+ groups = "eth_mdio_y",
+ "eth_mdc_y",
+ "eth_rgmii_rx_clk_y",
+ "eth_rx_dv_y",
+ "eth_rxd0_y",
+ "eth_rxd1_y",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_y",
+ "eth_txd0_y",
+ "eth_txd1_y",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
};
};
--
2.15.1
^ permalink raw reply related
* [PATCH v3 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board
From: Yixun Lan @ 2017-12-15 2:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215021014.231308-1-yixun.lan@amlogic.com>
This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..b8c4f1913d28 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -20,3 +20,10 @@
&uart_AO {
status = "okay";
};
+
+ðmac {
+ status = "okay";
+ phy-mode = "rgmii";
+ pinctrl-0 = <ð_rgmii_y_pins>;
+ pinctrl-names = "default";
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 1/2] soc: imx: gpc: Add i.MX6SX PCI power domain
From: Fabio Estevam @ 2017-12-15 2:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
i.MX6SX has a PCI power domain in PGC. Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Documentation/devicetree/bindings/power/fsl,imx-gpc.txt | 3 +++
drivers/soc/imx/gpc.c | 16 +++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
index e371b26..441f71e 100644
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -9,6 +9,7 @@ Required properties:
- fsl,imx6q-gpc
- fsl,imx6qp-gpc
- fsl,imx6sl-gpc
+ - fsl,imx6sx-gpc
- reg: should be register base and length as documented in the
datasheet
- interrupts: Should contain one interrupt specifier for the GPC interrupt
@@ -29,6 +30,8 @@ Required properties:
PU_DOMAIN 1
The following additional DOMAIN_INDEX value is valid for i.MX6SL:
DISPLAY_DOMAIN 2
+ The following additional DOMAIN_INDEX value is valid for i.MX6SX:
+ PCI_DOMAIN 3
- #power-domain-cells: Should be 0
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index 47e7aa9..53f7275 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -273,7 +273,15 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x240,
.cntr_pdn_bit = 4,
- }
+ }, {
+ .base = {
+ .name = "PCI",
+ .power_off = imx6_pm_domain_power_off,
+ .power_on = imx6_pm_domain_power_on,
+ },
+ .reg_offs = 0x200,
+ .cntr_pdn_bit = 6,
+ },
};
struct imx_gpc_dt_data {
@@ -296,10 +304,16 @@ static const struct imx_gpc_dt_data imx6sl_dt_data = {
.err009619_present = false,
};
+static const struct imx_gpc_dt_data imx6sx_dt_data = {
+ .num_domains = 4,
+ .err009619_present = false,
+};
+
static const struct of_device_id imx_gpc_dt_ids[] = {
{ .compatible = "fsl,imx6q-gpc", .data = &imx6q_dt_data },
{ .compatible = "fsl,imx6qp-gpc", .data = &imx6qp_dt_data },
{ .compatible = "fsl,imx6sl-gpc", .data = &imx6sl_dt_data },
+ { .compatible = "fsl,imx6sx-gpc", .data = &imx6sx_dt_data },
{ }
};
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx6sx: Add support for PCI power domain
From: Fabio Estevam @ 2017-12-15 2:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513304698-15169-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Previously PCI support was working because the bootloader has previously
powered up the PCI power domain.
Represent the PCI power domain, so that PCI is functional without
relying on the PCI support from the bootloader.
Tested on a imx6sx-sdb board with no PCI support in the bootloader.
Reported-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6sx.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 40c6738c..c6ea6ec 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -750,6 +750,19 @@
#interrupt-cells = <3>;
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&intc>;
+ clocks = <&clks IMX6SX_CLK_IPG>;
+ clock-names = "ipg";
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_pci: power-domain at 3 {
+ reg = <3>;
+ #power-domain-cells = <0>;
+ power-supply = <®_pcie>;
+ };
+ };
};
iomuxc: iomuxc at 20e0000 {
@@ -1328,6 +1341,7 @@
<&clks IMX6SX_CLK_PCIE_REF_125M>,
<&clks IMX6SX_CLK_DISPLAY_AXI>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_inbound_axi";
+ power-domains = <&pd_pci>;
status = "disabled";
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: don't set vtimer->cnt_ctl in kvm_arch_timer_handler
From: Jia He @ 2017-12-15 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214154518.GX910@cbox>
On 12/14/2017 11:45 PM, Christoffer Dall Wrote:
> On Thu, Dec 14, 2017 at 11:28:04PM +0800, Jia He wrote:
>> On 12/14/2017 9:09 PM, Christoffer Dall Wrote:
>>> On Thu, Dec 14, 2017 at 12:57:54PM +0800, Jia He wrote:
>>> Hi Jia,
>>>
>>>> I have tried your newer level-mapped-v7 branch, but bug is still there.
>>>>
>>>> There is no special load in both host and guest. The guest (kernel
>>>> 4.14) is often hanging when booting
>>>>
>>>> the guest kernel log
>>>>
>>>> [ OK ] Reached target Remote File Systems.
>>>> Starting File System Check on /dev/mapper/fedora-root...
>>>> [ OK ] Started File System Check on /dev/mapper/fedora-root.
>>>> Mounting /sysroot...
>>>> [ 2.670764] SGI XFS with ACLs, security attributes, no debug enabled
>>>> [ 2.678180] XFS (dm-0): Mounting V5 Filesystem
>>>> [ 2.740364] XFS (dm-0): Ending clean mount
>>>> [ OK ] Mounted /sysroot.
>>>> [ OK ] Reached target Initrd Root File System.
>>>> Starting Reload Configuration from the Real Root...
>>>> [ 61.288215] INFO: rcu_sched detected stalls on CPUs/tasks:
>>>> [ 61.290791] 1-...!: (0 ticks this GP) idle=574/0/0 softirq=5/5 fqs=1
>>>> [ 61.293664] (detected by 0, t=6002 jiffies, g=-263, c=-264, q=39760)
>>>> [ 61.296480] Task dump for CPU 1:
>>>> [ 61.297938] swapper/1 R running task 0 0 1 0x00000020
>>>> [ 61.300643] Call trace:
>>>> [ 61.301260] __switch_to+0x6c/0x78
>>>> [ 61.302095] cpu_number+0x0/0x8
>>>> [ 61.302867] rcu_sched kthread starved for 6000 jiffies!
>>>> g18446744073709551353 c18446744073709551352 f0x0 RCU_GP_WAIT_FQS(3)
>>>> ->state=0x402 ->cpu=1
>>>> [ 61.305941] rcu_sched I 0 8 2 0x00000020
>>>> [ 61.307250] Call trace:
>>>> [ 61.307854] __switch_to+0x6c/0x78
>>>> [ 61.308693] __schedule+0x268/0x8f0
>>>> [ 61.309545] schedule+0x2c/0x88
>>>> [ 61.310325] schedule_timeout+0x84/0x3b8
>>>> [ 61.311278] rcu_gp_kthread+0x4d4/0x7d8
>>>> [ 61.312213] kthread+0x134/0x138
>>>> [ 61.313001] ret_from_fork+0x10/0x1c
>>>>
>>>> Maybe my previous patch is not perfect enough, thanks for your comments.
>>>>
>>>> I digged it futher more, do you think below code logic is possibly
>>>> problematic?
>>>>
>>>>
>>>> vtimer_save_state?????????? (vtimer->loaded = false, cntv_ctl is 0)
>>>>
>>>> kvm_arch_timer_handler????????(read cntv_ctl and set vtimer->cnt_ctl = 0)
>>>>
>>>> vtimer_restore_state ? ? ? ? ?? (write vtimer->cnt_ctl to cntv_ctl,
>>>> then cntv_ctl will
>>>>
>>>> ??? ??? ??? ??? ?? ? ? be 0 forever)
>>>>
>>>>
>>>> If above analysis is reasonable
>>> Yes, I think there's something there if the hardware doesn't retire the
>>> signal fast enough...
>>>
>>>> how about below patch? already
>>>> tested in my arm64 server.
>>>>
>>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>>> index f9555b1..ee6dd3f 100644
>>>> --- a/virt/kvm/arm/arch_timer.c
>>>> +++ b/virt/kvm/arm/arch_timer.c
>>>> @@ -99,7 +99,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq,
>>>> void *dev_id)
>>>> ??????? }
>>>> ??????? vtimer = vcpu_vtimer(vcpu);
>>>>
>>>> -?????? if (!vtimer->irq.level) {
>>>> +?????? if (vtimer->loaded && !vtimer->irq.level) {
>>>> ??????????????? vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
>>>> ??????????????? if (kvm_timer_irq_can_fire(vtimer))
>>>> ??????????????????????? kvm_timer_update_irq(vcpu, true, vtimer);
>>>>
>>> There's nothing really wrong with that patch, I just didn't think it
>>> would be necessary, as we really shouldn't see interrupts if the timer
>>> is not loaded. Can you confirm that a WARN_ON(!vtimer->loaded) in
>>> kvm_arch_timer_handler() gives you a splat?
>> Please see the WARN_ON result (without my patch)
>> [?? 72.171706] WARNING: CPU: 24 PID: 1768 at
>> arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:101
>> kvm_arch_timer_handler+0xc0/0xc8
>>
>>> Also, could you give the following a try (without your patch):
>>>
>>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>>> index 73d262c4712b..4751255345d1 100644
>>> --- a/virt/kvm/arm/arch_timer.c
>>> +++ b/virt/kvm/arm/arch_timer.c
>>> @@ -367,6 +367,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>>> /* Disable the virtual timer */
>>> write_sysreg_el0(0, cntv_ctl);
>>> + isb();
>> No luck? the bug is still there
>>
> ok, so this is a slightly different approach to what you were trying to
> do. Can you please give this a try and let me know how it goes?
>
This patch fixes the bug in our platform.
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 73d262c4712b..544ed15fbbb3 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -46,7 +46,7 @@ static const struct kvm_irq_level default_vtimer_irq = {
> .level = 1,
> };
>
> -static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx);
> +static bool kvm_timer_irq_can_fire(u32 cnt_ctl);
> static void kvm_timer_update_irq(struct kvm_vcpu *vcpu, bool new_level,
> struct arch_timer_context *timer_ctx);
> static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx);
> @@ -94,6 +94,7 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> {
> struct kvm_vcpu *vcpu = *(struct kvm_vcpu **)dev_id;
> struct arch_timer_context *vtimer;
> + u32 cnt_ctl;
>
> if (!vcpu) {
> pr_warn_once("Spurious arch timer IRQ on non-VCPU thread\n");
> @@ -101,8 +102,8 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> + cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(cnt_ctl))
> kvm_timer_update_irq(vcpu, true, vtimer);
IIUC, your patch makes kvm_arch_timer_handler never changesvtimer->cnt_ctl
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> @@ -148,10 +149,10 @@ static u64 kvm_timer_compute_delta(struct arch_timer_context *timer_ctx)
> return 0;
> }
>
> -static bool kvm_timer_irq_can_fire(struct arch_timer_context *timer_ctx)
> +static bool kvm_timer_irq_can_fire(u32 cnt_ctl)
> {
> - return !(timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
> - (timer_ctx->cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
> + return !(cnt_ctl & ARCH_TIMER_CTRL_IT_MASK) &&
> + (cnt_ctl & ARCH_TIMER_CTRL_ENABLE);
> }
>
> /*
> @@ -164,10 +165,10 @@ static u64 kvm_timer_earliest_exp(struct kvm_vcpu *vcpu)
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>
> - if (kvm_timer_irq_can_fire(vtimer))
> + if (kvm_timer_irq_can_fire(vtimer->cnt_ctl))
> min_virt = kvm_timer_compute_delta(vtimer);
>
> - if (kvm_timer_irq_can_fire(ptimer))
> + if (kvm_timer_irq_can_fire(ptimer->cnt_ctl))
> min_phys = kvm_timer_compute_delta(ptimer);
>
> /* If none of timers can fire, then return 0 */
> @@ -231,7 +232,7 @@ static bool kvm_timer_should_fire(struct arch_timer_context *timer_ctx)
> {
> u64 cval, now;
>
> - if (!kvm_timer_irq_can_fire(timer_ctx))
> + if (!kvm_timer_irq_can_fire(timer_ctx->cnt_ctl))
> return false;
>
> cval = timer_ctx->cnt_cval;
> @@ -306,7 +307,7 @@ static void phys_timer_emulate(struct kvm_vcpu *vcpu)
> * don't need to have a soft timer scheduled for the future. If the
> * timer cannot fire at all, then we also don't need a soft timer.
> */
> - if (kvm_timer_should_fire(ptimer) || !kvm_timer_irq_can_fire(ptimer)) {
> + if (kvm_timer_should_fire(ptimer) || !kvm_timer_irq_can_fire(ptimer->cnt_ctl)) {
> soft_timer_cancel(&timer->phys_timer, NULL);
> return;
> }
> @@ -367,6 +368,7 @@ static void vtimer_save_state(struct kvm_vcpu *vcpu)
>
> /* Disable the virtual timer */
> write_sysreg_el0(0, cntv_ctl);
> + isb();
My only concern is whether this isb() is required here?
Sorryif this is a stupid question.I understand little about arm arch
memory barrier. But seems isb will flush all the instruction prefetch.Do
you think if an timer interrupt irq arrives, arm will use the previous
instruction prefetch?
Cheers,
Jia
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6sx-sdb: Disable PCI support
From: Fabio Estevam @ 2017-12-15 2:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513271667-1960-1-git-send-email-festevam@gmail.com>
Hi Shawn,
On Thu, Dec 14, 2017 at 3:14 PM, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> When I added PCI support for this board I was testing with mainline U-Boot,
> which has PCI support and enables the i.mx6sx PCI power domain.
>
> When running on a U-Boot without PCI support, such as the one provided
> by NXP a kernel hang is observed.
>
> Better to disable the pci node for now, until the i.MX6SX PCI power domain
> is properly implemented in the kernel.
Just sent two patches that add i.MX6SX PCI power domain support.
If they are accepted then this one can be discarded.
Patch 2/2 of this series should still be applied though.
Thanks
^ permalink raw reply
* [PATCH v2] ARM64: dts: meson-axg: add PWM DT info for Meson-Axg SoC
From: Yixun Lan @ 2017-12-15 2:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Jian Hu <jian.hu@amlogic.com>
Add PWM DT info for the Amlogic's Meson-Axg SoC.
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
Changes in v2 since [1]
- drop clock DT info from soc.dtsi
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005578.html
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 112 +++++++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index a0d7b10da512..1ee5f12115b6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -120,6 +120,20 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xffd00000 0x0 0x25000>;
+ pwm_ab: pwm at 1b000 {
+ compatible = "amlogic,meson-axg-ee-pwm";
+ reg = <0x0 0x1b000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_cd: pwm at 1a000 {
+ compatible = "amlogic,meson-axg-ee-pwm";
+ reg = <0x0 0x1a000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart_A: serial at 24000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-uart";
reg = <0x0 0x24000 0x0 0x14>;
@@ -180,6 +194,90 @@
#gpio-cells = <2>;
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+
+ pwm_a_a_pins: pwm_a_a {
+ mux {
+ groups = "pwm_a_a";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_x18_pins: pwm_a_x18 {
+ mux {
+ groups = "pwm_a_x18";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_x20_pins: pwm_a_x20 {
+ mux {
+ groups = "pwm_a_x20";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_a_z_pins: pwm_a_z {
+ mux {
+ groups = "pwm_a_z";
+ function = "pwm_a";
+ };
+ };
+
+ pwm_b_a_pins: pwm_b_a {
+ mux {
+ groups = "pwm_b_a";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_b_x_pins: pwm_b_x {
+ mux {
+ groups = "pwm_b_x";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_b_z_pins: pwm_b_z {
+ mux {
+ groups = "pwm_b_z";
+ function = "pwm_b";
+ };
+ };
+
+ pwm_c_a_pins: pwm_c_a {
+ mux {
+ groups = "pwm_c_a";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_c_x10_pins: pwm_c_x10 {
+ mux {
+ groups = "pwm_c_x10";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_c_x17_pins: pwm_c_x17 {
+ mux {
+ groups = "pwm_c_x17";
+ function = "pwm_c";
+ };
+ };
+
+ pwm_d_x11_pins: pwm_d_x11 {
+ mux {
+ groups = "pwm_d_x11";
+ function = "pwm_d";
+ };
+ };
+
+ pwm_d_x16_pins: pwm_d_x16 {
+ mux {
+ groups = "pwm_d_x16";
+ function = "pwm_d";
+ };
+ };
};
};
@@ -225,6 +323,20 @@
};
};
+ pwm_AO_ab: pwm at 7000 {
+ compatible = "amlogic,meson-axg-ao-pwm";
+ reg = <0x0 0x07000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
+ pwm_AO_cd: pwm at 2000 {
+ compatible = "amlogic,axg-ao-pwm";
+ reg = <0x0 0x02000 0x0 0x20>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
uart_AO: serial at 3000 {
compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
reg = <0x0 0x3000 0x0 0x18>;
--
2.15.1
^ permalink raw reply related
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-15 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b37e86d-eee3-c51e-eceb-5d0c7ad12886@huawei.com>
Hi James,
On 2017/12/7 14:37, gengdongjiu wrote:
>> We need to tackle (1) and (3) separately. For (3) we need some API that lets
>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't have
>> a way of migrating pending SError yet... which is where I got stuck last time I
>> was looking at this.
> I understand you most idea.
>
> But In the Qemu one signal type can only correspond to one behavior, can not correspond to two behaviors,
> otherwise Qemu will do not know how to do.
>
> For the Qemu, if it receives the SIGBUS_MCEERR_AR signal, it will populate the CPER
> records and inject a SEA to guest through KVM IOCTL "KVM_SET_ONE_REG"; if receives the SIGBUS_MCEERR_AO
> signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
>
> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>
> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
>
> not involve _trigger_ an SError.
>
> so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
As I explained above:
If Qemu received SIGBUS_MCEERR_AR, it will record CPER and trigger Synchronous External Abort;
If Qemu received SIGBUS_MCEERR_AO, it will record CPER and trigger GPIO IRQ;
So Qemu does not know when to _trigger_ an SError.
so here I "return a error" to Qemu if ghes_notify_sei() return failure in [1], if you opposed KVM "return error",
do you have a better idea about it? thanks
About the way of migrating pending SError, I think it is a separate case, because Qemu still does not know
how and when to trigger the SError.
[1]:
static int kvm_handle_guest_sei(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
.......................
+ case ESR_ELx_AET_UER: /* The error has not been propagated */
+ /*
+ * Userspace only handle the guest SError Interrupt(SEI) if the
+ * error has not been propagated
+ */
+ run->exit_reason = KVM_EXIT_EXCEPTION;
+ run->ex.exception = ESR_ELx_EC_SERROR;
+ run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
+ return 0;
.......................
}
>
^ permalink raw reply
* [PATCH] arm64: allwinner: a64: a64-olinuxino: add usb otg
From: kbuild test robot @ 2017-12-15 3:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513058169-25516-1-git-send-email-jagan@amarulasolutions.com>
Hi Jagan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.15-rc3]
[cannot apply to next-20171214]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Jagan-Teki/arm64-allwinner-a64-a64-olinuxino-add-usb-otg/20171215-084728
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
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
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts:204.1-15 Label or path reg_drivevbus not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37312 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171215/86724236/attachment-0001.gz>
^ permalink raw reply
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