* [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 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
* 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
* [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
* [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: 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] 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
* [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] 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
* 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
* 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: Rob Herring @ 2017-12-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc7M3jeV_hNBBRJKGs3vtNzdrGbW_YETw2n0fXxhqjZ_g@mail.gmail.com>
On Thu, Dec 14, 2017 at 2:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
>> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
>> 50 - arch/arm/boot/dts/exynos5250-spring.dts
>> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
>> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>>
>
> Sure, I can take care of this but in such case it would be better if
> Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
> base my patch on top of his... but there might be conflicts when
> applying to my tree.
>
> Different topic - why not enabling these warnings by default?
Because the warning police don't like lots of warnings. Neither did
Linus, but he only sees the unittest ones[1]. The ones that are actual
binding errors rather than best practice are on by default.
The plan is to enable once the warnings are all gone.
Rob
[1] https://www.spinics.net/lists/devicetree/msg202057.html
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Use lower case hex addresses in node names
From: Krzysztof Kozlowski @ 2017-12-14 21:02 UTC (permalink / raw)
To: linux-arm-kernel
Convert all hex addresses in node names to lower case to fix warnings
like:
arch/arm/boot/dts/exynos5422-odroidhc1.dtb: Warning (simple_bus_reg):
Node /soc/nocp at 10CA1000 simple-bus unit address format error, expected "10ca1000"
Conversion was done using sed:
$ sed -e 's/@\(.*\) {/@\L\1 {/' -i arch/arm/boot/dts/exynos*.dts*
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/boot/dts/exynos3250.dtsi | 34 ++++++++--------
arch/arm/boot/dts/exynos4.dtsi | 56 +++++++++++++-------------
arch/arm/boot/dts/exynos4210.dtsi | 8 ++--
arch/arm/boot/dts/exynos4412-pinctrl.dtsi | 2 +-
arch/arm/boot/dts/exynos4412.dtsi | 22 +++++------
arch/arm/boot/dts/exynos5.dtsi | 22 +++++------
arch/arm/boot/dts/exynos5250.dtsi | 66 +++++++++++++++----------------
arch/arm/boot/dts/exynos5260.dtsi | 26 ++++++------
arch/arm/boot/dts/exynos5420.dtsi | 44 ++++++++++-----------
arch/arm/boot/dts/exynos5440.dtsi | 14 +++----
10 files changed, 147 insertions(+), 147 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
index 2bd3872221a1..8d47571b3984 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -164,31 +164,31 @@
syscon = <&pmu_system_controller>;
};
- pd_cam: cam-power-domain at 10023C00 {
+ pd_cam: cam-power-domain at 10023c00 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x20>;
#power-domain-cells = <0>;
};
- pd_mfc: mfc-power-domain at 10023C40 {
+ pd_mfc: mfc-power-domain at 10023c40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
#power-domain-cells = <0>;
};
- pd_g3d: g3d-power-domain at 10023C60 {
+ pd_g3d: g3d-power-domain at 10023c60 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C60 0x20>;
#power-domain-cells = <0>;
};
- pd_lcd0: lcd0-power-domain at 10023C80 {
+ pd_lcd0: lcd0-power-domain at 10023c80 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C80 0x20>;
#power-domain-cells = <0>;
};
- pd_isp: isp-power-domain at 10023CA0 {
+ pd_isp: isp-power-domain at 10023ca0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
#power-domain-cells = <0>;
@@ -204,7 +204,7 @@
<&cmu CLK_FIN_PLL>;
};
- cmu_dmc: clock-controller at 105C0000 {
+ cmu_dmc: clock-controller at 105c0000 {
compatible = "samsung,exynos3250-cmu-dmc";
reg = <0x105C0000 0x2000>;
#clock-cells = <1>;
@@ -219,7 +219,7 @@
status = "disabled";
};
- tmu: tmu at 100C0000 {
+ tmu: tmu at 100c0000 {
compatible = "samsung,exynos3250-tmu";
reg = <0x100C0000 0x100>;
interrupts = <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>;
@@ -287,7 +287,7 @@
status = "disabled";
};
- sysmmu_jpeg: sysmmu at 11A60000 {
+ sysmmu_jpeg: sysmmu at 11a60000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11a60000 0x1000>;
interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
@@ -313,7 +313,7 @@
status = "disabled";
};
- dsi_0: dsi at 11C80000 {
+ dsi_0: dsi at 11c80000 {
compatible = "samsung,exynos3250-mipi-dsi";
reg = <0x11C80000 0x10000>;
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
@@ -328,7 +328,7 @@
status = "disabled";
};
- sysmmu_fimd0: sysmmu at 11E20000 {
+ sysmmu_fimd0: sysmmu at 11e20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11e20000 0x1000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>,
@@ -386,7 +386,7 @@
status = "disabled";
};
- exynos_usbphy: exynos-usbphy at 125B0000 {
+ exynos_usbphy: exynos-usbphy at 125b0000 {
compatible = "samsung,exynos3250-usb2-phy";
reg = <0x125B0000 0x100>;
samsung,pmureg-phandle = <&pmu_system_controller>;
@@ -425,7 +425,7 @@
};
};
- adc: adc at 126C0000 {
+ adc: adc at 126c0000 {
compatible = "samsung,exynos3250-adc",
"samsung,exynos-adc-v2";
reg = <0x126C0000 0x100>;
@@ -544,7 +544,7 @@
status = "disabled";
};
- i2c_4: i2c at 138A0000 {
+ i2c_4: i2c at 138a0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -557,7 +557,7 @@
status = "disabled";
};
- i2c_5: i2c at 138B0000 {
+ i2c_5: i2c at 138b0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -570,7 +570,7 @@
status = "disabled";
};
- i2c_6: i2c at 138C0000 {
+ i2c_6: i2c at 138c0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -583,7 +583,7 @@
status = "disabled";
};
- i2c_7: i2c at 138D0000 {
+ i2c_7: i2c at 138d0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -641,7 +641,7 @@
status = "disabled";
};
- pwm: pwm at 139D0000 {
+ pwm: pwm at 139d0000 {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D0000 0x1000>;
interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2db6cfe5d908..f44aa383f626 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -101,28 +101,28 @@
syscon = <&pmu_system_controller>;
};
- pd_mfc: mfc-power-domain at 10023C40 {
+ pd_mfc: mfc-power-domain at 10023c40 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C40 0x20>;
#power-domain-cells = <0>;
label = "MFC";
};
- pd_g3d: g3d-power-domain at 10023C60 {
+ pd_g3d: g3d-power-domain at 10023c60 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C60 0x20>;
#power-domain-cells = <0>;
label = "G3D";
};
- pd_lcd0: lcd0-power-domain at 10023C80 {
+ pd_lcd0: lcd0-power-domain at 10023c80 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C80 0x20>;
#power-domain-cells = <0>;
label = "LCD0";
};
- pd_tv: tv-power-domain at 10023C20 {
+ pd_tv: tv-power-domain at 10023c20 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C20 0x20>;
#power-domain-cells = <0>;
@@ -130,21 +130,21 @@
label = "TV";
};
- pd_cam: cam-power-domain at 10023C00 {
+ pd_cam: cam-power-domain at 10023c00 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x20>;
#power-domain-cells = <0>;
label = "CAM";
};
- pd_gps: gps-power-domain at 10023CE0 {
+ pd_gps: gps-power-domain at 10023ce0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CE0 0x20>;
#power-domain-cells = <0>;
label = "GPS";
};
- pd_gps_alive: gps-alive-power-domain at 10023D00 {
+ pd_gps_alive: gps-alive-power-domain at 10023d00 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023D00 0x20>;
#power-domain-cells = <0>;
@@ -184,7 +184,7 @@
interrupt-parent = <&gic>;
};
- dsi_0: dsi at 11C80000 {
+ dsi_0: dsi at 11c80000 {
compatible = "samsung,exynos4210-mipi-dsi";
reg = <0x11C80000 0x10000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
@@ -297,7 +297,7 @@
status = "disabled";
};
- keypad: keypad at 100A0000 {
+ keypad: keypad at 100a0000 {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A0000 0x100>;
interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
@@ -342,7 +342,7 @@
status = "disabled";
};
- exynos_usbphy: exynos-usbphy at 125B0000 {
+ exynos_usbphy: exynos-usbphy at 125b0000 {
compatible = "samsung,exynos4210-usb2-phy";
reg = <0x125B0000 0x100>;
samsung,pmureg-phandle = <&pmu_system_controller>;
@@ -538,7 +538,7 @@
status = "disabled";
};
- i2c_4: i2c at 138A0000 {
+ i2c_4: i2c at 138a0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -551,7 +551,7 @@
status = "disabled";
};
- i2c_5: i2c at 138B0000 {
+ i2c_5: i2c at 138b0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -564,7 +564,7 @@
status = "disabled";
};
- i2c_6: i2c at 138C0000 {
+ i2c_6: i2c at 138c0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -577,7 +577,7 @@
status = "disabled";
};
- i2c_7: i2c at 138D0000 {
+ i2c_7: i2c at 138d0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-i2c";
@@ -590,7 +590,7 @@
status = "disabled";
};
- i2c_8: i2c at 138E0000 {
+ i2c_8: i2c at 138e0000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samsung,s3c2440-hdmiphy-i2c";
@@ -651,7 +651,7 @@
status = "disabled";
};
- pwm: pwm at 139D0000 {
+ pwm: pwm at 139d0000 {
compatible = "samsung,exynos4210-pwm";
reg = <0x139D0000 0x1000>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
@@ -720,7 +720,7 @@
status = "disabled";
};
- tmu: tmu at 100C0000 {
+ tmu: tmu at 100c0000 {
#include "exynos4412-tmu-sensor-conf.dtsi"
};
@@ -743,7 +743,7 @@
iommus = <&sysmmu_rotator>;
};
- hdmi: hdmi at 12D00000 {
+ hdmi: hdmi at 12d00000 {
compatible = "samsung,exynos4210-hdmi";
reg = <0x12D00000 0x70000>;
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
@@ -759,7 +759,7 @@
status = "disabled";
};
- hdmicec: cec at 100B0000 {
+ hdmicec: cec at 100b0000 {
compatible = "samsung,s5p-cec";
reg = <0x100B0000 0x200>;
interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
@@ -772,7 +772,7 @@
status = "disabled";
};
- mixer: mixer at 12C10000 {
+ mixer: mixer at 12c10000 {
compatible = "samsung,exynos4210-mixer";
interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
reg = <0x12C10000 0x2100>, <0x12c00000 0x300>;
@@ -911,7 +911,7 @@
#iommu-cells = <0>;
};
- sysmmu_tv: sysmmu at 12E20000 {
+ sysmmu_tv: sysmmu at 12e20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x12E20000 0x1000>;
interrupt-parent = <&combiner>;
@@ -922,7 +922,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc0: sysmmu at 11A20000 {
+ sysmmu_fimc0: sysmmu at 11a20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11A20000 0x1000>;
interrupt-parent = <&combiner>;
@@ -933,7 +933,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc1: sysmmu at 11A30000 {
+ sysmmu_fimc1: sysmmu at 11a30000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11A30000 0x1000>;
interrupt-parent = <&combiner>;
@@ -944,7 +944,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc2: sysmmu at 11A40000 {
+ sysmmu_fimc2: sysmmu at 11a40000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11A40000 0x1000>;
interrupt-parent = <&combiner>;
@@ -955,7 +955,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc3: sysmmu at 11A50000 {
+ sysmmu_fimc3: sysmmu at 11a50000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11A50000 0x1000>;
interrupt-parent = <&combiner>;
@@ -966,7 +966,7 @@
#iommu-cells = <0>;
};
- sysmmu_jpeg: sysmmu at 11A60000 {
+ sysmmu_jpeg: sysmmu at 11a60000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11A60000 0x1000>;
interrupt-parent = <&combiner>;
@@ -977,7 +977,7 @@
#iommu-cells = <0>;
};
- sysmmu_rotator: sysmmu at 12A30000 {
+ sysmmu_rotator: sysmmu at 12a30000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x12A30000 0x1000>;
interrupt-parent = <&combiner>;
@@ -987,7 +987,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimd0: sysmmu at 11E20000 {
+ sysmmu_fimd0: sysmmu at 11e20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11E20000 0x1000>;
interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 03dd61f64809..ce161ad1215d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -82,7 +82,7 @@
};
};
- pd_lcd1: lcd1-power-domain at 10023CA0 {
+ pd_lcd1: lcd1-power-domain at 10023ca0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
#power-domain-cells = <0>;
@@ -156,7 +156,7 @@
reg = <0x03860000 0x1000>;
};
- tmu: tmu at 100C0000 {
+ tmu: tmu at 100c0000 {
compatible = "samsung,exynos4210-tmu";
interrupt-parent = <&combiner>;
reg = <0x100C0000 0x100>;
@@ -229,7 +229,7 @@
};
};
- mixer: mixer at 12C10000 {
+ mixer: mixer at 12c10000 {
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp", "mout_mixer",
"sclk_mixer";
clocks = <&clock CLK_MIXER>, <&clock CLK_HDMI>,
@@ -245,7 +245,7 @@
status = "disabled";
};
- sysmmu_g2d: sysmmu at 12A20000 {
+ sysmmu_g2d: sysmmu at 12a20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x12A20000 0x1000>;
interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos4412-pinctrl.dtsi b/arch/arm/boot/dts/exynos4412-pinctrl.dtsi
index 4eebd4721a5f..ef7b89d3db9e 100644
--- a/arch/arm/boot/dts/exynos4412-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4412-pinctrl.dtsi
@@ -925,7 +925,7 @@
};
};
- pinctrl_3: pinctrl at 106E0000 {
+ pinctrl_3: pinctrl at 106e0000 {
gpv0: gpv0 {
gpio-controller;
#gpio-cells = <2>;
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 282525ac7554..cec5bef44bdb 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -38,7 +38,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu0: cpu at A00 {
+ cpu0: cpu at a00 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA00>;
@@ -50,21 +50,21 @@
#cooling-cells = <2>; /* min followed by max */
};
- cpu at A01 {
+ cpu at a01 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA01>;
operating-points-v2 = <&cpu0_opp_table>;
};
- cpu at A02 {
+ cpu at a02 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA02>;
operating-points-v2 = <&cpu0_opp_table>;
};
- cpu at A03 {
+ cpu at a03 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0xA03>;
@@ -168,7 +168,7 @@
};
};
- pd_isp: isp-power-domain at 10023CA0 {
+ pd_isp: isp-power-domain at 10023ca0 {
compatible = "samsung,exynos4210-pd";
reg = <0x10023CA0 0x20>;
#power-domain-cells = <0>;
@@ -233,7 +233,7 @@
samsung,syscon-phandle = <&pmu_system_controller>;
};
- adc: adc at 126C0000 {
+ adc: adc at 126c0000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x126C0000 0x100>;
interrupt-parent = <&combiner>;
@@ -272,7 +272,7 @@
status = "disabled";
};
- fimc_lite_1: fimc-lite at 123A0000 {
+ fimc_lite_1: fimc-lite at 123a0000 {
compatible = "samsung,exynos4212-fimc-lite";
reg = <0x123A0000 0x1000>;
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
@@ -385,7 +385,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_fd: sysmmu at 122A0000 {
+ sysmmu_fimc_fd: sysmmu at 122a0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x122A0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -396,7 +396,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_mcuctl: sysmmu at 122B0000 {
+ sysmmu_fimc_mcuctl: sysmmu at 122b0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x122B0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -407,7 +407,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_lite0: sysmmu at 123B0000 {
+ sysmmu_fimc_lite0: sysmmu at 123b0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x123B0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -419,7 +419,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_lite1: sysmmu at 123C0000 {
+ sysmmu_fimc_lite1: sysmmu at 123c0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x123C0000 0x1000>;
interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index b3c8428de389..1b1dd3850638 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -106,31 +106,31 @@
reg = <0x10050000 0x5000>;
};
- serial_0: serial at 12C00000 {
+ serial_0: serial at 12c00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
};
- serial_1: serial at 12C10000 {
+ serial_1: serial at 12c10000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C10000 0x100>;
interrupts = <GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>;
};
- serial_2: serial at 12C20000 {
+ serial_2: serial at 12c20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C20000 0x100>;
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
};
- serial_3: serial at 12C30000 {
+ serial_3: serial at 12c30000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C30000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
};
- i2c_0: i2c at 12C60000 {
+ i2c_0: i2c at 12c60000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C60000 0x100>;
interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
@@ -140,7 +140,7 @@
status = "disabled";
};
- i2c_1: i2c at 12C70000 {
+ i2c_1: i2c at 12c70000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C70000 0x100>;
interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
@@ -150,7 +150,7 @@
status = "disabled";
};
- i2c_2: i2c at 12C80000 {
+ i2c_2: i2c at 12c80000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C80000 0x100>;
interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
@@ -160,7 +160,7 @@
status = "disabled";
};
- i2c_3: i2c at 12C90000 {
+ i2c_3: i2c at 12c90000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12C90000 0x100>;
interrupts = <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>;
@@ -170,14 +170,14 @@
status = "disabled";
};
- pwm: pwm at 12DD0000 {
+ pwm: pwm at 12dd0000 {
compatible = "samsung,exynos4210-pwm";
reg = <0x12DD0000 0x100>;
samsung,pwm-outputs = <0>, <1>, <2>, <3>;
#pwm-cells = <3>;
};
- rtc: rtc at 101E0000 {
+ rtc: rtc at 101e0000 {
compatible = "samsung,s3c6410-rtc";
reg = <0x101E0000 0x100>;
interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
@@ -195,7 +195,7 @@
status = "disabled";
};
- dp: dp-controller at 145B0000 {
+ dp: dp-controller at 145b0000 {
compatible = "samsung,exynos5-dp";
reg = <0x145B0000 0x1000>;
interrupts = <10 3>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index bdd742e3f3c3..571c89605a39 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -132,7 +132,7 @@
label = "G3D";
};
- pd_disp1: power-domain at 100440A0 {
+ pd_disp1: power-domain at 100440a0 {
compatible = "samsung,exynos4210-pd";
reg = <0x100440A0 0x20>;
#power-domain-cells = <0>;
@@ -143,7 +143,7 @@
clock-names = "oscclk", "clk0", "clk1";
};
- pd_mau: power-domain at 100440C0 {
+ pd_mau: power-domain at 100440c0 {
compatible = "samsung,exynos4210-pd";
reg = <0x100440C0 0x20>;
#power-domain-cells = <0>;
@@ -180,7 +180,7 @@
clock-frequency = <24000000>;
};
- mct at 101C0000 {
+ mct at 101c0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x101C0000 0x800>;
interrupt-controller;
@@ -252,7 +252,7 @@
interrupt-parent = <&gic>;
};
- watchdog at 101D0000 {
+ watchdog at 101d0000 {
compatible = "samsung,exynos5250-wdt";
reg = <0x101D0000 0x100>;
interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
@@ -272,7 +272,7 @@
iommu-names = "left", "right";
};
- rotator: rotator at 11C00000 {
+ rotator: rotator at 11c00000 {
compatible = "samsung,exynos5250-rotator";
reg = <0x11C00000 0x64>;
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
@@ -290,7 +290,7 @@
#include "exynos4412-tmu-sensor-conf.dtsi"
};
- sata: sata at 122F0000 {
+ sata: sata at 122f0000 {
compatible = "snps,dwc-ahci";
samsung,sata-freq = <66>;
reg = <0x122F0000 0x1ff>;
@@ -313,7 +313,7 @@
};
/* i2c_0-3 are defined in exynos5.dtsi */
- i2c_4: i2c at 12CA0000 {
+ i2c_4: i2c at 12ca0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CA0000 0x100>;
interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
@@ -326,7 +326,7 @@
status = "disabled";
};
- i2c_5: i2c at 12CB0000 {
+ i2c_5: i2c at 12cb0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CB0000 0x100>;
interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
@@ -339,7 +339,7 @@
status = "disabled";
};
- i2c_6: i2c at 12CC0000 {
+ i2c_6: i2c at 12cc0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CC0000 0x100>;
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
@@ -352,7 +352,7 @@
status = "disabled";
};
- i2c_7: i2c at 12CD0000 {
+ i2c_7: i2c at 12cd0000 {
compatible = "samsung,s3c2440-i2c";
reg = <0x12CD0000 0x100>;
interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
@@ -365,7 +365,7 @@
status = "disabled";
};
- i2c_8: i2c at 12CE0000 {
+ i2c_8: i2c at 12ce0000 {
compatible = "samsung,s3c2440-hdmiphy-i2c";
reg = <0x12CE0000 0x1000>;
interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
@@ -381,7 +381,7 @@
};
};
- i2c_9: i2c at 121D0000 {
+ i2c_9: i2c at 121d0000 {
compatible = "samsung,exynos5-sata-phy-i2c";
reg = <0x121D0000 0x100>;
#address-cells = <1>;
@@ -505,7 +505,7 @@
power-domains = <&pd_mau>;
};
- i2s1: i2s at 12D60000 {
+ i2s1: i2s at 12d60000 {
compatible = "samsung,s3c6410-i2s";
status = "disabled";
reg = <0x12D60000 0x100>;
@@ -519,7 +519,7 @@
power-domains = <&pd_mau>;
};
- i2s2: i2s at 12D70000 {
+ i2s2: i2s at 12d70000 {
compatible = "samsung,s3c6410-i2s";
status = "disabled";
reg = <0x12D70000 0x100>;
@@ -606,7 +606,7 @@
interrupt-parent = <&gic>;
ranges;
- pdma0: pdma at 121A0000 {
+ pdma0: pdma at 121a0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
@@ -617,7 +617,7 @@
#dma-requests = <32>;
};
- pdma1: pdma at 121B0000 {
+ pdma1: pdma at 121b0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
@@ -639,7 +639,7 @@
#dma-requests = <1>;
};
- mdma1: mdma at 11C10000 {
+ mdma1: mdma at 11c10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
@@ -706,7 +706,7 @@
status = "disabled";
};
- hdmicec: cec at 101B0000 {
+ hdmicec: cec at 101b0000 {
compatible = "samsung,s5p-cec";
reg = <0x101B0000 0x200>;
interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
@@ -737,7 +737,7 @@
#phy-cells = <0>;
};
- adc: adc at 12D10000 {
+ adc: adc at 12d10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>;
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
@@ -749,7 +749,7 @@
status = "disabled";
};
- sysmmu_g2d: sysmmu at 10A60000 {
+ sysmmu_g2d: sysmmu at 10a60000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x10A60000 0x1000>;
interrupt-parent = <&combiner>;
@@ -781,7 +781,7 @@
#iommu-cells = <0>;
};
- sysmmu_rotator: sysmmu at 11D40000 {
+ sysmmu_rotator: sysmmu at 11d40000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11D40000 0x1000>;
interrupt-parent = <&combiner>;
@@ -791,7 +791,7 @@
#iommu-cells = <0>;
};
- sysmmu_jpeg: sysmmu at 11F20000 {
+ sysmmu_jpeg: sysmmu at 11f20000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x11F20000 0x1000>;
interrupt-parent = <&combiner>;
@@ -822,7 +822,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_fd: sysmmu at 132A0000 {
+ sysmmu_fimc_fd: sysmmu at 132a0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x132A0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -852,7 +852,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_mcuctl: sysmmu at 132B0000 {
+ sysmmu_fimc_mcuctl: sysmmu at 132b0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x132B0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -862,7 +862,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_odc: sysmmu at 132C0000 {
+ sysmmu_fimc_odc: sysmmu at 132c0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x132C0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -872,7 +872,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_dis0: sysmmu at 132D0000 {
+ sysmmu_fimc_dis0: sysmmu at 132d0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x132D0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -892,7 +892,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_3dnr: sysmmu at 132F0000 {
+ sysmmu_fimc_3dnr: sysmmu at 132f0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x132F0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -902,7 +902,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_lite0: sysmmu at 13C40000 {
+ sysmmu_fimc_lite0: sysmmu at 13c40000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13C40000 0x1000>;
interrupt-parent = <&combiner>;
@@ -913,7 +913,7 @@
#iommu-cells = <0>;
};
- sysmmu_fimc_lite1: sysmmu at 13C50000 {
+ sysmmu_fimc_lite1: sysmmu at 13c50000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13C50000 0x1000>;
interrupt-parent = <&combiner>;
@@ -924,7 +924,7 @@
#iommu-cells = <0>;
};
- sysmmu_gsc0: sysmmu at 13E80000 {
+ sysmmu_gsc0: sysmmu at 13e80000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E80000 0x1000>;
interrupt-parent = <&combiner>;
@@ -935,7 +935,7 @@
#iommu-cells = <0>;
};
- sysmmu_gsc1: sysmmu at 13E90000 {
+ sysmmu_gsc1: sysmmu at 13e90000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13E90000 0x1000>;
interrupt-parent = <&combiner>;
@@ -946,7 +946,7 @@
#iommu-cells = <0>;
};
- sysmmu_gsc2: sysmmu at 13EA0000 {
+ sysmmu_gsc2: sysmmu at 13ea0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13EA0000 0x1000>;
interrupt-parent = <&combiner>;
@@ -957,7 +957,7 @@
#iommu-cells = <0>;
};
- sysmmu_gsc3: sysmmu at 13EB0000 {
+ sysmmu_gsc3: sysmmu at 13eb0000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x13EB0000 0x1000>;
interrupt-parent = <&combiner>;
diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
index 5e88c9645975..12c6b011576b 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -106,13 +106,13 @@
#clock-cells = <1>;
};
- clock_g2d: clock-controller at 10A00000 {
+ clock_g2d: clock-controller at 10a00000 {
compatible = "samsung,exynos5260-clock-g2d";
reg = <0x10A00000 0x10000>;
#clock-cells = <1>;
};
- clock_mif: clock-controller at 10CE0000 {
+ clock_mif: clock-controller at 10ce0000 {
compatible = "samsung,exynos5260-clock-mif";
reg = <0x10CE0000 0x10000>;
#clock-cells = <1>;
@@ -130,25 +130,25 @@
#clock-cells = <1>;
};
- clock_fsys: clock-controller at 122E0000 {
+ clock_fsys: clock-controller at 122e0000 {
compatible = "samsung,exynos5260-clock-fsys";
reg = <0x122E0000 0x10000>;
#clock-cells = <1>;
};
- clock_aud: clock-controller at 128C0000 {
+ clock_aud: clock-controller at 128c0000 {
compatible = "samsung,exynos5260-clock-aud";
reg = <0x128C0000 0x10000>;
#clock-cells = <1>;
};
- clock_isp: clock-controller at 133C0000 {
+ clock_isp: clock-controller at 133c0000 {
compatible = "samsung,exynos5260-clock-isp";
reg = <0x133C0000 0x10000>;
#clock-cells = <1>;
};
- clock_gscl: clock-controller at 13F00000 {
+ clock_gscl: clock-controller at 13f00000 {
compatible = "samsung,exynos5260-clock-gscl";
reg = <0x13F00000 0x10000>;
#clock-cells = <1>;
@@ -179,7 +179,7 @@
reg = <0x10000000 0x100>;
};
- mct: mct at 100B0000 {
+ mct: mct at 100b0000 {
compatible = "samsung,exynos4210-mct";
reg = <0x100B0000 0x1000>;
clocks = <&fin_pll>, <&clock_peri PERI_CLK_MCT>;
@@ -198,7 +198,7 @@
<GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
};
- cci: cci at 10F00000 {
+ cci: cci at 10f00000 {
compatible = "arm,cci-400";
#address-cells = <1>;
#size-cells = <1>;
@@ -236,18 +236,18 @@
interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
};
- pinctrl_2: pinctrl at 128B0000 {
+ pinctrl_2: pinctrl at 128b0000 {
compatible = "samsung,exynos5260-pinctrl";
reg = <0x128B0000 0x1000>;
interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>;
};
- pmu_system_controller: system-controller at 10D50000 {
+ pmu_system_controller: system-controller at 10d50000 {
compatible = "samsung,exynos5260-pmu", "syscon";
reg = <0x10D50000 0x10000>;
};
- uart0: serial at 12C00000 {
+ uart0: serial at 12c00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
@@ -256,7 +256,7 @@
status = "disabled";
};
- uart1: serial at 12C10000 {
+ uart1: serial at 12c10000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C10000 0x100>;
interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>;
@@ -265,7 +265,7 @@
status = "disabled";
};
- uart2: serial at 12C20000 {
+ uart2: serial at 12c20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C20000 0x100>;
interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index e451b7b4d1ca..340443e2f004 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -238,37 +238,37 @@
status = "disabled";
};
- nocp_mem0_0: nocp at 10CA1000 {
+ nocp_mem0_0: nocp at 10ca1000 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1000 0x200>;
status = "disabled";
};
- nocp_mem0_1: nocp at 10CA1400 {
+ nocp_mem0_1: nocp at 10ca1400 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1400 0x200>;
status = "disabled";
};
- nocp_mem1_0: nocp at 10CA1800 {
+ nocp_mem1_0: nocp at 10ca1800 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1800 0x200>;
status = "disabled";
};
- nocp_mem1_1: nocp at 10CA1C00 {
+ nocp_mem1_1: nocp at 10ca1c00 {
compatible = "samsung,exynos5420-nocp";
reg = <0x10CA1C00 0x200>;
status = "disabled";
};
- nocp_g3d_0: nocp at 11A51000 {
+ nocp_g3d_0: nocp at 11a51000 {
compatible = "samsung,exynos5420-nocp";
reg = <0x11A51000 0x200>;
status = "disabled";
};
- nocp_g3d_1: nocp at 11A51400 {
+ nocp_g3d_1: nocp at 11a51400 {
compatible = "samsung,exynos5420-nocp";
reg = <0x11A51400 0x200>;
status = "disabled";
@@ -310,7 +310,7 @@
label = "MSC";
};
- disp_pd: power-domain at 100440C0 {
+ disp_pd: power-domain at 100440c0 {
compatible = "samsung,exynos4210-pd";
reg = <0x100440C0 0x20>;
#power-domain-cells = <0>;
@@ -323,7 +323,7 @@
clock-names = "oscclk", "clk0", "clk1", "clk2", "asb0", "asb1";
};
- mau_pd: power-domain at 100440E0 {
+ mau_pd: power-domain at 100440e0 {
compatible = "samsung,exynos4210-pd";
reg = <0x100440E0 0x20>;
#power-domain-cells = <0>;
@@ -386,7 +386,7 @@
power-domains = <&mau_pd>;
};
- pdma0: pdma at 121A0000 {
+ pdma0: pdma at 121a0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
@@ -397,7 +397,7 @@
#dma-requests = <32>;
};
- pdma1: pdma at 121B0000 {
+ pdma1: pdma at 121b0000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
@@ -419,7 +419,7 @@
#dma-requests = <1>;
};
- mdma1: mdma at 11C10000 {
+ mdma1: mdma at 11c10000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
@@ -460,7 +460,7 @@
status = "disabled";
};
- i2s1: i2s at 12D60000 {
+ i2s1: i2s at 12d60000 {
compatible = "samsung,exynos5420-i2s";
reg = <0x12D60000 0x100>;
dmas = <&pdma1 12
@@ -476,7 +476,7 @@
status = "disabled";
};
- i2s2: i2s at 12D70000 {
+ i2s2: i2s@12d70000 {
compatible = "samsung,exynos5420-i2s";
reg = <0x12D70000 0x100>;
dmas = <&pdma0 12
@@ -565,7 +565,7 @@
status = "disabled";
};
- adc: adc at 12D10000 {
+ adc: adc@12d10000 {
compatible = "samsung,exynos-adc-v2";
reg = <0x12D10000 0x100>;
interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
@@ -577,7 +577,7 @@
status = "disabled";
};
- hsi2c_8: i2c at 12E00000 {
+ hsi2c_8: i2c at 12e00000 {
compatible = "samsung,exynos5250-hsi2c";
reg = <0x12E00000 0x1000>;
interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
@@ -590,7 +590,7 @@
status = "disabled";
};
- hsi2c_9: i2c at 12E10000 {
+ hsi2c_9: i2c at 12e10000 {
compatible = "samsung,exynos5250-hsi2c";
reg = <0x12E10000 0x1000>;
interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
@@ -603,7 +603,7 @@
status = "disabled";
};
- hsi2c_10: i2c at 12E20000 {
+ hsi2c_10: i2c at 12e20000 {
compatible = "samsung,exynos5250-hsi2c";
reg = <0x12E20000 0x1000>;
interrupts = <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>;
@@ -632,11 +632,11 @@
#sound-dai-cells = <0>;
};
- hdmiphy: hdmiphy at 145D0000 {
+ hdmiphy: hdmiphy at 145d0000 {
reg = <0x145D0000 0x20>;
};
- hdmicec: cec at 101B0000 {
+ hdmicec: cec at 101b0000 {
compatible = "samsung,s5p-cec";
reg = <0x101B0000 0x200>;
interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
@@ -661,7 +661,7 @@
status = "disabled";
};
- rotator: rotator at 11C00000 {
+ rotator: rotator at 11c00000 {
compatible = "samsung,exynos5250-rotator";
reg = <0x11C00000 0x64>;
interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
@@ -690,7 +690,7 @@
iommus = <&sysmmu_gscl1>;
};
- jpeg_0: jpeg at 11F50000 {
+ jpeg_0: jpeg at 11f50000 {
compatible = "samsung,exynos5420-jpeg";
reg = <0x11F50000 0x1000>;
interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
@@ -699,7 +699,7 @@
iommus = <&sysmmu_jpeg0>;
};
- jpeg_1: jpeg at 11F60000 {
+ jpeg_1: jpeg at 11f60000 {
compatible = "samsung,exynos5420-jpeg";
reg = <0x11F60000 0x1000>;
interrupts = <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 9c3c75ae5e48..3acf3f2d643e 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -35,7 +35,7 @@
#clock-cells = <1>;
};
- gic: interrupt-controller at 2E0000 {
+ gic: interrupt-controller at 2e0000 {
compatible = "arm,cortex-a15-gic";
#interrupt-cells = <3>;
interrupt-controller;
@@ -108,7 +108,7 @@
>;
};
- serial_0: serial at B0000 {
+ serial_0: serial at b0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xB0000 0x1000>;
interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
@@ -116,7 +116,7 @@
clock-names = "uart", "clk_uart_baud0";
};
- serial_1: serial at C0000 {
+ serial_1: serial at c0000 {
compatible = "samsung,exynos4210-uart";
reg = <0xC0000 0x1000>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
@@ -124,7 +124,7 @@
clock-names = "uart", "clk_uart_baud0";
};
- spi_0: spi at D0000 {
+ spi_0: spi at d0000 {
compatible = "samsung,exynos5440-spi";
reg = <0xD0000 0x100>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
@@ -136,7 +136,7 @@
clock-names = "spi", "spi_busclk0";
};
- pin_ctrl: pinctrl at E0000 {
+ pin_ctrl: pinctrl at e0000 {
compatible = "samsung,exynos5440-pinctrl";
reg = <0xE0000 0x1000>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
@@ -168,7 +168,7 @@
};
};
- i2c at F0000 {
+ i2c at f0000 {
compatible = "samsung,exynos5440-i2c";
reg = <0xF0000 0x1000>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
@@ -233,7 +233,7 @@
#include "exynos5440-tmu-sensor-conf.dtsi"
};
- tmuctrl_1: tmuctrl at 16011C {
+ tmuctrl_1: tmuctrl at 16011c {
compatible = "samsung,exynos5440-tmu";
reg = <0x16011C 0x230>, <0x160368 0x10>;
interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>;
--
2.11.0
^ permalink raw reply related
* DT dtc warnings
From: Krzysztof Kozlowski @ 2017-12-14 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc7M3jeV_hNBBRJKGs3vtNzdrGbW_YETw2n0fXxhqjZ_g@mail.gmail.com>
On Thu, Dec 14, 2017 at 9:40 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> Please help fix these. More checks are being added[2].
>>
>> Rob
>>
>> [1] https://patchwork.kernel.org/patch/10112725/
>> [2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html
>>
>>
>> 77 - arch/arm/boot/dts/prima2-evb.dts
>>
>> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
>> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow.dts
>> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
>> 50 - arch/arm/boot/dts/exynos5250-spring.dts
>> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
>> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
>> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
>> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>>
>
> Sure, I can take care of this but in such case it would be better if
> Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
> base my patch on top of his... but there might be conflicts when
> applying to my tree.
>
> Different topic - why not enabling these warnings by default?
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?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/3] staging: vchiq_arm: Remove useless comments
From: Greg KH @ 2017-12-14 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ca203ae9222beeff6b6f2eda829e0cea702cd4e.1513283180.git.lameli67@gmail.com>
On Thu, Dec 14, 2017 at 11:40:03PM +0300, Mikhail Shvetsov wrote:
> Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
I can't take patches without any changelog text at all.
Please fix all of these up and resend.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Greg KH @ 2017-12-14 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3484237.SQf3uXUed3@avalon>
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.)
> On a side note, Joe pointed out that some files contains BSD license text
> similar to
>
> * * Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
>
> If we follow the text of the license strictly it can be argued that such text
> can't be replaced by an SPDX license identifier without breaching the license.
That's not really true, see Thomas's patch series that adds the BSD
license to the kernel source tree in a way that preserves the license
text and legality of it all. It follows the agreed-apon process
documented in the REUSE Inititive which is driven by the FSFE:
https://reuse.software/
Once Thomas's series is merged, and we've cleaned up all of the GPL
boilerplate text, then we can start to worry about the BSD license mess :)
Does this help?
greg k-h
^ permalink raw reply
* DT dtc warnings
From: Santosh Shilimkar @ 2017-12-14 20:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJKCzjx3zNigu_0T=Ku=_P2SQEjTx=uVbvr_QxJQR7kYg@mail.gmail.com>
Hui Rob,
12/14/2017 10:21 AM, Rob Herring wrote:
> Hi all,
>
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
>
> Please help fix these. More checks are being added[2].
>
[...]
>
> 52 - arch/arm/boot/dts/keystone-k2e-evm.dts
> 73 - arch/arm/boot/dts/keystone-k2l-evm.dts
> 97 - arch/arm/boot/dts/keystone-k2hk-evm.dts
>
Nishant is going to help me to address keystone ones.
Regards,
Santosh
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-14 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214200851.GA27849@kroah.com>
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.
On a side note, Joe pointed out that some files contains BSD license text
similar to
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
If we follow the text of the license strictly it can be argued that such text
can't be replaced by an SPDX license identifier without breaching the license.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* DT dtc warnings
From: Krzysztof Kozlowski @ 2017-12-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJKCzjx3zNigu_0T=Ku=_P2SQEjTx=uVbvr_QxJQR7kYg@mail.gmail.com>
On Thu, Dec 14, 2017 at 7:21 PM, Rob Herring <robh@kernel.org> wrote:
> Hi all,
>
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
>
> Please help fix these. More checks are being added[2].
>
> Rob
>
> [1] https://patchwork.kernel.org/patch/10112725/
> [2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html
>
>
> 77 - arch/arm/boot/dts/prima2-evb.dts
>
> 50 - arch/arm/boot/dts/exynos5250-arndale.dts
> 50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
> 50 - arch/arm/boot/dts/exynos5250-snow.dts
> 50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
> 50 - arch/arm/boot/dts/exynos5250-spring.dts
> 71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
> 71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
> 71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
> 71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
> 71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
>
Sure, I can take care of this but in such case it would be better if
Mathieu's (+Cc) patch would be split per-subarch maintainer. I can
base my patch on top of his... but there might be conflicts when
applying to my tree.
Different topic - why not enabling these warnings by default?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 3/3] staging: vchiq_arm: Fixing code lines over 80 characters
From: Mikhail Shvetsov @ 2017-12-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513283180.git.lameli67@gmail.com>
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 48f05062fc12..7a803d136987 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -87,7 +87,8 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
goto failed;
} else if (i > 0) {
vchiq_log_warning(vchiq_core_log_level,
- "%s: videocore initialized after %d retries\n", __func__, i);
+ "%s: videocore initialized after %d retries\n",
+ __func__, i);
}
instance = kzalloc(sizeof(*instance), GFP_KERNEL);
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] staging: vchiq_arm: Fixing code style of comments
From: Mikhail Shvetsov @ 2017-12-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513283180.git.lameli67@gmail.com>
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
.../vc04_services/interface/vchiq_arm/vchiq_kern_lib.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 4a40b9b31a5a..48f05062fc12 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -72,7 +72,9 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
vchiq_log_trace(vchiq_core_log_level, "%s called", __func__);
/* VideoCore may not be ready due to boot up timing.
- It may never be ready if kernel and firmware are mismatched, so don't block forever. */
+ * It may never be ready if kernel and firmware are mismatched, so don't
+ * block forever.
+ */
for (i = 0; i < VCHIQ_INIT_RETRIES; i++) {
state = vchiq_get_state();
if (state)
@@ -381,8 +383,9 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if ((bulk->data != data) ||
(bulk->size != size)) {
/* This is not a retry of the previous one.
- ** Cancel the signal when the transfer
- ** completes. */
+ * Cancel the signal when the transfer
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
@@ -408,7 +411,8 @@ vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
if (bulk) {
/* Cancel the signal when the transfer
- ** completes. */
+ * completes.
+ */
spin_lock(&bulk_waiter_spinlock);
bulk->userdata = NULL;
spin_unlock(&bulk_waiter_spinlock);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] staging: vchiq_arm: Remove useless comments
From: Mikhail Shvetsov @ 2017-12-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1513283180.git.lameli67@gmail.com>
Signed-off-by: Mikhail Shvetsov <lameli67@gmail.com>
---
.../interface/vchiq_arm/vchiq_kern_lib.c | 35 +---------------------
1 file changed, 1 insertion(+), 34 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
index 34f746db19cd..4a40b9b31a5a 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_kern_lib.c
@@ -31,7 +31,6 @@
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-/* ---- Include Files ---------------------------------------------------- */
#include <linux/kernel.h>
#include <linux/module.h>
@@ -41,9 +40,6 @@
#include "vchiq_arm.h"
#include "vchiq_killable.h"
-/* ---- Public Variables ------------------------------------------------- */
-
-/* ---- Private Constants and Types -------------------------------------- */
struct bulk_waiter_node {
struct bulk_waiter bulk_waiter;
@@ -64,11 +60,7 @@ static VCHIQ_STATUS_T
vchiq_blocking_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle, void *data,
unsigned int size, VCHIQ_BULK_DIR_T dir);
-/****************************************************************************
-*
-* vchiq_initialise
-*
-***************************************************************************/
+
#define VCHIQ_INIT_RETRIES 10
VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
{
@@ -120,11 +112,6 @@ VCHIQ_STATUS_T vchiq_initialise(VCHIQ_INSTANCE_T *instance_out)
}
EXPORT_SYMBOL(vchiq_initialise);
-/****************************************************************************
-*
-* vchiq_shutdown
-*
-***************************************************************************/
VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
{
@@ -168,22 +155,12 @@ VCHIQ_STATUS_T vchiq_shutdown(VCHIQ_INSTANCE_T instance)
}
EXPORT_SYMBOL(vchiq_shutdown);
-/****************************************************************************
-*
-* vchiq_is_connected
-*
-***************************************************************************/
static int vchiq_is_connected(VCHIQ_INSTANCE_T instance)
{
return instance->connected;
}
-/****************************************************************************
-*
-* vchiq_connect
-*
-***************************************************************************/
VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
{
@@ -214,11 +191,6 @@ VCHIQ_STATUS_T vchiq_connect(VCHIQ_INSTANCE_T instance)
}
EXPORT_SYMBOL(vchiq_connect);
-/****************************************************************************
-*
-* vchiq_add_service
-*
-***************************************************************************/
VCHIQ_STATUS_T vchiq_add_service(
VCHIQ_INSTANCE_T instance,
@@ -259,11 +231,6 @@ VCHIQ_STATUS_T vchiq_add_service(
}
EXPORT_SYMBOL(vchiq_add_service);
-/****************************************************************************
-*
-* vchiq_open_service
-*
-***************************************************************************/
VCHIQ_STATUS_T vchiq_open_service(
VCHIQ_INSTANCE_T instance,
--
2.11.0
^ permalink raw reply related
* [PATCH 0/3] staging: vchiq_arm: code style fixing
From: Mikhail Shvetsov @ 2017-12-14 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ee4ad6c7-9d5e-bd66-4738-148dddb69ef5@i2se.com>
Mikhail Shvetsov (3):
Remove useless comments
Fixing code style of comments
Fixing code lines over 80 characters
.../interface/vchiq_arm/vchiq_kern_lib.c | 50 +++++-----------------
1 file changed, 11 insertions(+), 39 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Boris Brezillon @ 2017-12-14 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214210120.6b436e0d@bbrezillon>
On Thu, 14 Dec 2017 21:01:20 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> Hi Rob,
>
> On Wed, 13 Dec 2017 16:57:50 -0600
> Rob Herring <robh+dt@kernel.org> wrote:
>
> > On Wed, Dec 13, 2017 at 12:53 PM, Alexandre Belloni
> > <alexandre.belloni@free-electrons.com> wrote:
> > > The clocksource and clockevent timer are probed early in the boot process.
> > > At that time it is difficult for linux to know whether a particular timer
> > > can be used as the clocksource or the clockevent or by another driver,
> > > especially when they are all identical or have similar features.
> >
> > If all identical, then it shouldn't matter. "similar" means some
> > difference. Describe those differences.
>
> We had this discussion already. Those timers might be connected to
> external pins and may serve the role of PWM generators or capture
> devices. We can also chain timers and provide a clocksource with a
> better resolution or one that wraps less often. In the end it's all
> about how the user plans to use its system, and this has to be
> described somehow. Assuming that the software can decide by itself
> which timer should be used or how many of them should be chained is
> just an utopia.
>
> >
> > > Until now, multiple strategies have been used to solve that:
> > > - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
> >
> > Compile time probably means only one option is really used.
>
> Compile time selection prevents using the same kernel for different
> boards (in other words, no multi-v7), so not really an option here.
>
> >
> > > - use a kernel parameter as the "clocksource" early_param in mach-omap2
> >
> > Yeah, OMAP was one of the previous times this came up and also
> > attempted something like this. This parameter predates selecting
> > timers based on features described in DT. Look at commit
> > 2eb03937df3ebc (ARM: OMAP3: Update clocksource timer selection).
>
> Then, would you accept to have a property saying that a specific timer
> is a free-running timer (suitable for clocksource) or a programmable
> timer (suitable for clkevent)? Or are you saying that you don't like the
> way timers are differentiated on omap?
>
> >
> > > - registering the first seen timer as a clockevent and the second one as
> > > a clocksource as in rk_timer_init or dw_apb_timer_init
> > >
> > > Add a linux,clocksource and a linux,clockevent node in chosen with a timer
> > > property pointing to the timer to use. Other properties, like the targeted
> > > precision may be added later.
> >
> > Open ended expansion of this does not help convince me it is needed.
>
> It's not an open ended expansion, we're just trying to find a way to
> describe which timer blocks should be used as free running timers
> (clksource) and which one should be used as programmable timers
> (clkevent). Automatically selecting timer blocks to assign to the
> clkevent or clocksource is not so easy (as has been explained earlier)
> because at the time the system registers its clksource/clkevent devices
> we might not have all the necessary information to know which timer
> blocks will be reserved for other usage later on. The use case I have
> in mind is DT overlays, where one of the overlay is using a timer as a
> PWM generator. If the clkevent or clksource has already claimed the
> timer connected to the pins the overlay is using, then we're screwed,
> and there's no way the system can know that ahead of time except by
> pre-assigning a timer to the clksource or clkevent feature.
>
> So really, we need a way to assign a specific timer to a specific
> feature. You've refused the different proposals we made so far, so
> what's your alternative? I mean a real alternative that solve the "an
> auto-selected timer might be claimed by another driver at some point"
> problem.
Okay, it seems I was wrong, you already agreed on a generic
atmel,tcb-timer compatible [1], so it seems the only thing we're missing
is a way to assign a timer to a clocksource or a clkevent.
[1]https://patchwork.kernel.org/patch/9755341/
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Greg KH @ 2017-12-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2967655.MWOA0IsQOS@avalon>
On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> Hi Joe,
>
> (CC'ing Greg and adding context for easier understanding)
>
> 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?
thanks,
greg k-h
^ 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