* [PATCH v2] arm64: dma-mapping: clear buffers allocated with FORCE_CONTIGUOUS flag
From: Catalin Marinas @ 2018-06-18 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180612110840.30436-1-m.szyprowski@samsung.com>
Hi Marek,
On Tue, Jun 12, 2018 at 01:08:40PM +0200, Marek Szyprowski wrote:
> dma_alloc_*() buffers might be exposed to userspace via mmap() call, so
> they should be cleared on allocation. In case of IOMMU-based dma-mapping
> implementation such buffer clearing was missing in the code path for
> DMA_ATTR_FORCE_CONTIGUOUS flag handling, because dma_alloc_from_contiguous()
> doesn't honor __GFP_ZERO flag. This patch fixes this issue. For more
> information on clearing buffers allocated by dma_alloc_* functions,
> see commit 6829e274a623 ("arm64: dma-mapping: always clear allocated
> buffers").
>
> Fixes: 44176bb38fa4 ("arm64: Add support for DMA_ATTR_FORCE_CONTIGUOUS to IOMMU")
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
I'll queue this patch for -rc2 but I hope a proper fix goes into the CMA
code.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] power: vexpress: fix corruption in notifier registration
From: Sudeep Holla @ 2018-06-18 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145608.GA26780@e107981-ln.cambridge.arm.com>
On 18/06/18 15:56, Lorenzo Pieralisi wrote:
> On Mon, Jun 18, 2018 at 12:40:07PM +0100, Sudeep Holla wrote:
>> Vexpress platforms provide two different restart handlers: SYS_REBOOT
>> that restart the entire system, while DB_RESET only restarts the
>> daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT
>> if it exists.
>>
>> notifier_chain_register used in register_restart_handler by design
>> allows notifier to be registered once only, however vexpress restart
>> notifier can get registered twice.
>
> Nit: I would say "notifier_chain_register() relies on notifiers to be
> registered only once to work properly"; put it differently, it allows
> notifiers to be registered twice (ie it does nothing to prevent it),
> that's why we have this issue.
>
Indeed. I saw there's notifier_chain_cond_register too, not sure why
that's not used everywhere. I will change from allows to relies in the
wording.
>> When this happen it corrupts list of notifiers, as result some
>> notifiers can be not called on proper event, traverse on list can be
>> cycled forever, and second unregister can access already freed memory.
>>
>> So far, since this was the only restart handler in the system, no issue
>> was observed even if the same notifier was registered twice. However
>> commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added
>> support for SP805 restart handlers and since the system under test
>> contains two vexpress restart and two SP805 watchdog instances, it was
>> observed that during the boot traversing the restart handler list looped
>> forever as there's a cycle in that list resulting in boot hang.
>>
>> This patch fixes the issues by ensuring that the notifier is installed
>> only once.
>>
>> Cc: Sebastian Reichel <sre@kernel.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>> ---
>> drivers/power/reset/vexpress-poweroff.c | 14 +++++++++-----
>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
>> index 102f95a09460..cdc68eb06a91 100644
>> --- a/drivers/power/reset/vexpress-poweroff.c
>> +++ b/drivers/power/reset/vexpress-poweroff.c
>> @@ -35,6 +35,7 @@ static void vexpress_reset_do(struct device *dev, const char *what)
>> }
>>
>> static struct device *vexpress_power_off_device;
>> +static atomic_t vexpress_restart_nb_refcnt = ATOMIC_INIT(0);
>>
>> static void vexpress_power_off(void)
>> {
>> @@ -96,13 +97,16 @@ static const struct of_device_id vexpress_reset_of_match[] = {
>>
>> static int _vexpress_register_restart_handler(struct device *dev)
>> {
>> - int err;
>> + int err = 0;
>
> Nit: I do not not see why you need to initialize err.
>
Yes, I did notice this just after I sent it out. Left over from my
debugging, will remove it.
>> vexpress_restart_device = dev;
>
> It is unclear to me how the !vexpress_restart_device sentinel is
> used while registering FUNC_RESET. It is unrelated to this patch
> but if the registration below fails for FUNC_REBOOT can we end
> up in a situation where vexpress_restart_device is initialized
> with no restart handler registered ?
>
Yes, it took sometime for me to understand that. IIUC, FUNC_RESET is
optional, so it's probed first then !vexpress_restart_device will be
used. FUNC_REBOOT will override FUNC_RESET but not other way around.
> By looking at it I am not a big fan of the vexpress_restart_device
> global variable it has been there since we merged this code but
> its usage is a bit obscure.
>
Yes, I was thinking of making access to it locked via mutex or some lock
but that won't fix the issue seen as it won't prevent FUNC_RESET being
probed first and then FUNC_REBOOT which will attempt to register
notifier again anyways.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] power: vexpress: fix corruption in notifier registration
From: Sudeep Holla @ 2018-06-18 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529322007-4637-1-git-send-email-sudeep.holla@arm.com>
Vexpress platforms provide two different restart handlers: SYS_REBOOT
that restart the entire system, while DB_RESET only restarts the
daughter board containing the CPU. DB_RESET is overridden by SYS_REBOOT
if it exists.
notifier_chain_register used in register_restart_handler by design
relies on notifiers to be registered once only, however vexpress restart
notifier can get registered twice. When this happen it corrupts list
of notifiers, as result some notifiers can be not called on proper
event, traverse on list can be cycled forever, and second unregister
can access already freed memory.
So far, since this was the only restart handler in the system, no issue
was observed even if the same notifier was registered twice. However
commit 6c5c0d48b686 ("watchdog: sp805: add restart handler") added
support for SP805 restart handlers and since the system under test
contains two vexpress restart and two SP805 watchdog instances, it was
observed that during the boot traversing the restart handler list looped
forever as there's a cycle in that list resulting in boot hang.
This patch fixes the issues by ensuring that the notifier is installed
only once.
Cc: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/power/reset/vexpress-poweroff.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
v1->v2:
- Updated changelog wordings as suggested by Lorenzo
- Dropped unnecessary error variable initialisation on stack
diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
index 102f95a09460..e9e749f87517 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -35,6 +35,7 @@ static void vexpress_reset_do(struct device *dev, const char *what)
}
static struct device *vexpress_power_off_device;
+static atomic_t vexpress_restart_nb_refcnt = ATOMIC_INIT(0);
static void vexpress_power_off(void)
{
@@ -99,10 +100,13 @@ static int _vexpress_register_restart_handler(struct device *dev)
int err;
vexpress_restart_device = dev;
- err = register_restart_handler(&vexpress_restart_nb);
- if (err) {
- dev_err(dev, "cannot register restart handler (err=%d)\n", err);
- return err;
+ if (atomic_inc_return(&vexpress_restart_nb_refcnt) == 1) {
+ err = register_restart_handler(&vexpress_restart_nb);
+ if (err) {
+ dev_err(dev, "cannot register restart handler (err=%d)\n", err);
+ atomic_dec(&vexpress_restart_nb_refcnt);
+ return err;
+ }
}
device_create_file(dev, &dev_attr_active);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 03/19] dt-bindings: sram: sunxi: Add A13 binding for the C1 SRAM region
From: Maxime Ripard @ 2018-06-18 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-4-paul.kocialkowski@bootlin.com>
On Mon, Jun 18, 2018 at 04:58:27PM +0200, Paul Kocialkowski wrote:
> This introduces a dedicated binding for the C1 SRAM region for the A13
> sunxi platform.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> index 5af5bafd5572..ddc82cbd7f4d 100644
> --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> @@ -32,6 +32,9 @@ The valid sections compatible for A10 are:
> - allwinner,sun4i-a10-sram-c1
> - allwinner,sun4i-a10-sram-d
>
> +The valid sections compatible for A13 are:
> + - allwinner,sun5i-a13-sram-c1
It supports more SRAM than that, namely the SRAM A3-A4, C1 and D, at
least.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/8a70d486/attachment.sig>
^ permalink raw reply
* [PATCH v4 01/19] dt-bindings: sram: sunxi: Add A13, A20 and A33 SRAM controller bindings
From: Maxime Ripard @ 2018-06-18 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-2-paul.kocialkowski@bootlin.com>
On Mon, Jun 18, 2018 at 04:58:25PM +0200, Paul Kocialkowski wrote:
> This introduces dedicated bindings for the SRAM controllers found on the
> A13, A20 and A33 sunxi platforms.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Explaining why you need to add these new compatibles would be great.
> diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> index d087f04a4d7f..19cc0b892672 100644
> --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> @@ -11,6 +11,9 @@ Controller Node
> Required properties:
> - compatible : should be:
> - "allwinner,sun4i-a10-sram-controller"
> + - "allwinner,sun5i-a13-sram-controller"
> + - "allwinner,sun7i-a20-sram-controller"
> + - "allwinner,sun8i-a33-sram-controller"
And I think Chen-Yu asked you to rename this compatible to
-system-controller for the previous iteration?
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/5f55c0f0/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: RIoTboard Add chosen stdout-path property
From: Lucas Stach @ 2018-06-18 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618154257.16919-1-manu@freebsd.org>
Am Montag, den 18.06.2018, 17:42 +0200 schrieb Emmanuel Vadot:
> The RIoTboard debug uart is connected to serial1.
> Add a chosen property in the DTS so OS knows what serial port to use for
> the console.
>
> > Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
> ---
> ?arch/arm/boot/dts/imx6dl-riotboard.dts | 4 ++++
> ?1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
> index 2e98c92adff7..315d2ae6fa45 100644
> --- a/arch/arm/boot/dts/imx6dl-riotboard.dts
> +++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
> @@ -19,6 +19,10 @@
> > ? reg = <0x10000000 0x40000000>;
> > ? };
> ?
> > + chosen {
> + stdout-path = "serial1:115200n8";
If there a reason to deviate from the "stdout-path = &uart1;" notation
used by other i.MX boards?
Regards,
Lucas
> + };
> +
> > ? regulators {
> > ? compatible = "simple-bus";
> > ? #address-cells = <1>;
^ permalink raw reply
* [PATCH 2/5] net: emaclite: Balance braces in else statement
From: Joe Perches @ 2018-06-18 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529322610-27215-3-git-send-email-radhey.shyam.pandey@xilinx.com>
On Mon, 2018-06-18 at 17:20 +0530, Radhey Shyam Pandey wrote:
> Remove else as it is not required with if doing a return.
> Fixes below checkpatch warning.
> WARNING: else is not generally useful after a break or return
checkpatch is stupid and doesn't understand code flow.
Always try to improve code flow instead of merely
following brainless instructions from a script.
So:
> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
[]
> @@ -569,13 +569,11 @@ static void xemaclite_tx_handler(struct net_device *dev)
> (u8 *) lp->deferred_skb->data,
> lp->deferred_skb->len) != 0)
> return;
> - else {
> - dev->stats.tx_bytes += lp->deferred_skb->len;
> - dev_kfree_skb_irq(lp->deferred_skb);
> - lp->deferred_skb = NULL;
> - netif_trans_update(dev); /* prevent tx timeout */
> - netif_wake_queue(dev);
> - }
> + dev->stats.tx_bytes += lp->deferred_skb->len;
> + dev_kfree_skb_irq(lp->deferred_skb);
> + lp->deferred_skb = NULL;
> + netif_trans_update(dev); /* prevent tx timeout */
> + netif_wake_queue(dev);
> }
> }
If you really want to redo this function, perhaps something like:
static void xemaclite_tx_handler(struct net_device *dev)
{
struct net_local *lp = netdev_priv(dev);
dev->stats.tx_packets++;
if (!lp->deferred_skb)
return;
if (xemaclite_send_data(lp, (u8 *)lp->deferred_skb->data,
lp->deferred_skb->len))
return;
dev->stats.tx_bytes += lp->deferred_skb->len;
dev_kfree_skb_irq(lp->deferred_skb);
lp->deferred_skb = NULL;
netif_trans_update(dev); /* prevent tx timeout */
netif_wake_queue(dev);
}
> @@ -1052,13 +1050,13 @@ static bool get_bool(struct platform_device *ofdev, const char *s)
> {
> u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
>
> - if (p) {
> + if (p)
> return (bool)*p;
> - } else {
> - dev_warn(&ofdev->dev, "Parameter %s not found,"
> +
> + dev_warn(&ofdev->dev, "Parameter %s not found,"
> "defaulting to false\n", s);
> - return false;
> - }
> +
> + return false;
> }
And this function has backward logic as the failure paths
are the ones that should return early or use a goto.
Perhaps something like:
static bool get_bool(struct platform_device *ofdev, const char *s)
{
u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
if (!p) {
dev_warn(&ofdev->dev,
"Parameter '%s' not found, defaulting to false\n", s);
return false;
}
return *p;
}
^ permalink raw reply
* [PATCH v4 04/19] dt-bindings: sram: sunxi: Add A20 binding for the C1 SRAM region
From: Maxime Ripard @ 2018-06-18 16:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618145843.14631-5-paul.kocialkowski@bootlin.com>
1;5202;0c
On Mon, Jun 18, 2018 at 04:58:28PM +0200, Paul Kocialkowski wrote:
> This introduces a dedicated binding for the C1 SRAM region for the A20
> sunxi platform.
>
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> index ddc82cbd7f4d..221fa7b42c18 100644
> --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
> @@ -35,6 +35,9 @@ The valid sections compatible for A10 are:
> The valid sections compatible for A13 are:
> - allwinner,sun5i-a13-sram-c1
>
> +The valid sections compatible for A20 are:
> + - allwinner,sun7i-a20-sram-c1
Same thing here, there's more supported SRAM than that. And maybe we
should just merge everything into the first patch? This looks like the
same commit over and over again.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/b7d236a9/attachment.sig>
^ permalink raw reply
* [PATCH v4 01/19] dt-bindings: sram: sunxi: Add A13, A20 and A33 SRAM controller bindings
From: Chen-Yu Tsai @ 2018-06-18 16:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618160250.ik44c3gcbdxylmyd@flea>
On Tue, Jun 19, 2018 at 12:02 AM, Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> On Mon, Jun 18, 2018 at 04:58:25PM +0200, Paul Kocialkowski wrote:
>> This introduces dedicated bindings for the SRAM controllers found on the
>> A13, A20 and A33 sunxi platforms.
>>
>> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> Explaining why you need to add these new compatibles would be great.
>
>> diff --git a/Documentation/devicetree/bindings/sram/sunxi-sram.txt b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
>> index d087f04a4d7f..19cc0b892672 100644
>> --- a/Documentation/devicetree/bindings/sram/sunxi-sram.txt
>> +++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
>> @@ -11,6 +11,9 @@ Controller Node
>> Required properties:
>> - compatible : should be:
>> - "allwinner,sun4i-a10-sram-controller"
>> + - "allwinner,sun5i-a13-sram-controller"
>> + - "allwinner,sun7i-a20-sram-controller"
>> + - "allwinner,sun8i-a33-sram-controller"
>
> And I think Chen-Yu asked you to rename this compatible to
> -system-controller for the previous iteration?
-system-control. It's not an actual controller, just a bunch of registers.
ChenYu
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor PCIe support
From: Sergei Shtylyov @ 2018-06-18 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618093623.s33bkiptazxem463@verge.net.au>
On 06/18/2018 12:36 PM, Simon Horman wrote:
>> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
>> 'renesas-devel-20180614v2-v4.17' tag. We're adding the R8A77980 PCIe related
>> device nodes and then enable PCIe on the Condor board. These patches depend
>> on the R8A77980 PCIe PHY driver support in order to work properly. Note that
>> in case the PCIe PHY driver is not enabled, the kernel will BUG() due to I/O
>> space page leak in the PCIe driver...
>
> Is that problem specific to the presence of PCIe nodes for
> condor/r8a77980
The nodes are safe unless they are enabled, so the Condor patch may be
deferred untl I fix the PCI code.
> condor/r8a77980 or is it also true of other (R-Car) boards where
> PCIe is enabled?
The leak happens every time the driver fails to probe later than
pci_remap_iospace() is called but the BUG_ON() is only triggered by rhe 2nd try
with EPROBE_DEFER returned previously.
> Regardless, it sounds like these patches expose a kernel bug.
> Is it being fixed?
I'm working on a fix (which embraces several PCI drivers)...
>> [1/2] arm64: dts: renesas: r8a77980: add PCIe support
>> [2/2] arm64: dts: renesas: condor: add PCIe support
WBR, Sergei
^ permalink raw reply
* [PATCH] arm64/acpi: Add fixup for HPE m400 quirks
From: James Morse @ 2018-06-18 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8a3034b9-6cf3-5182-717f-dd1dc8a087aa@infradead.org>
Hi Geoff,
On 15/06/18 18:17, Geoff Levand wrote:
> Just for background, this is a well known bug in the m400's AEPI/HEST
> firmware. There are a number of fixes out there the different distros
> have.
Thanks,
From:
https://bugzilla.redhat.com/show_bug.cgi?id=1574718
This is tripped by the ghes_probe() call, it finds an error has already occurred
before ghes code is initialized.
Does this still happen if you compile without CONFIG_PCI? (that is easily half
the dmesg that has happened before this point).
Disabling CONFIG_EFIVAR_FS would be interesting too, as that is firmware-code we
can't fix bugs in.
Your argument here is the that the firmware-vendor only build-tested their code,
and never noticed it notifies a fatal exception on startup. I find this hard to
believe, especially as these systems don't have EL3.
It's much more likely a driver is causing this, possibly because of bad data in
the firmware tables. I'd like to quirk the driver, so we can fix the next error
like this, as opposed to blindly continuing.
If it really is firmware, what is it doing that causes this error, and where
does it run? Disabling APEI is just reacting after the error has occurred, when
we could prevent it happening.
I can't reproduce this on a Mustang. I assume its the different ACPI tables, not
the kernel-config.
> I just put together this patch to unify things and have a
> common 'upstream' fix.
Wouldn't passing 'hest_disable' on the cmdline do the same for all kernel versions?
> On 06/15/2018 04:14 AM, James Morse wrote:
>> On 13/06/18 19:22, Geoff Levand wrote:
>>> Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
>>> a work-around for HPE ProLiant m400 APEI firmware problems.
>>>
>>> The work-around disables APEI when CONFIG_ACPI_APEI is set and
>>> m400 firmware is detected. Without this fixup m400 systems
>>> experience errors like these on startup:
>>>
>>> [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
>>> [Hardware Error]: event severity: fatal
>>> [Hardware Error]: Error 0, type: fatal
>>> [Hardware Error]: section_type: memory error
>>> [Hardware Error]: error_status: 0x0000000000001300
>>
>> "Access to a memory address which is not mapped to any component"
>>
>>
>>> [Hardware Error]: error_type: 10, invalid address
>>> Kernel panic - not syncing: Fatal hardware error!
>>
>> Why is this a problem?
>>
>> Surely this is a valid description of an error.
>
> The firmware bug causes this failure, not bad hardware.
I'm not talking about bad hardware here. What I think is happening is a software
bug is causing the CPU to make a bad access, which the RAS mechanism is
reporting like this because software would never be stupid enough to access an
address which is not mapped to any component! The RAS stuff believes this must
be address corruption.
I think this is a linux-driver bug, or a typo in the firmware tables, that cause
$non_existent_address to be mapped and probed.
>>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> index 7b09487ff8fb..3c315c2c7476 100644
>>> --- a/arch/arm64/kernel/acpi.c
>>> +++ b/arch/arm64/kernel/acpi.c
>>> +
>>> + if (!IS_ENABLED(CONFIG_ACPI_APEI) || hest_disable != HEST_ENABLED)
>>> + return;
>>> +
>>> + status = acpi_get_table(ACPI_SIG_HEST, 0, &header);
>>> +
>>> + if (ACPI_SUCCESS(status) && !strncmp(header->oem_id, "HPE ", 6) &&
>>> + !strncmp(header->oem_table_id, "ProLiant", 8) &&
>> You should match the affected range of OEM table revisions too, that way a
>> firmware upgrade should start working, instead of being permanently disabled
>> because we think its unlikely.
>
> The m400 has reached end of life. No one really expects to see any firmware
> update. I don't know what the effected OEM table revisions are, and I don't
> think there is an active platform maintainer who could give that info either.
>
> If someone can provide the info. I'll update the fix.
We can start with the version you have. You mention distro's have their own
fixes, hopefully they can supply the missing range of values.
>>> + MIDR_IMPLEMENTOR(read_cpuid_id()) == ARM_CPU_IMP_APM) {
>>
>> How is the CPU implementer relevant?
>
> That was just a copy of what other fixes had. Should I remove it?
The conclusion in the rest of this thread was HPE also produces ProLiant boxes
with a (presumably) identical HEST, but a totally different architecture.
Matching the DMI platform name as well would work round this. (or somewhere only
arm64 builds, with an appropriate comment in case we move it).
>> Nothing arch-specific here. You're adding this to arch/arm64 because
>> drivers/acpi/apei doesn't have an existing quirks table?
>
> There was a fix submitted that had it in drivers/acpi/scan.c, but the
> ACPI maintainer said he didn't want the fix in the main ACPI code.
Specifically about a HID-hack in the core device enumeration code, as opposed to
in the driver that claims it.
> See:
>
> https://lkml.org/lkml/2018/4/19/1020 (ACPI / scan: Fix regression related to X-Gene UARTs)
| 'some X-Gene based platforms (Mustang and M400) with invalid DSDT.'
... sounds familiar ...
And:
https://bugzilla.redhat.com/attachment.cgi?id=1144903&action=diff
Fixes a typo in firmware description of the GIC.
Why do we think this is a new kind of firmware bug, and not a repeat of the last
two? The only difference is this is being caught by the RAS code.
> The m400 is an arm64 platform, so it seems most appropriate to
> have it in arch/arm64/kernel/acpi.c.
We don't keep all drivers under arch/arm64, I'd really like to find the driver
that is causing this, and quirk it there.
If we have to bolt the hest-stable-door, drivers/acpi/apei/hest.c looks better,
it at least doesn't have to bodge around hest_disabled not being exposed in a
compatible way. If the maintainer objects, (as x86 hasn't had to do this yet),
then we can try drivers/acpi/arm64/hest_quirks.c.
When only once architecture had to quirk stuff based on the ACPI tables, the
arch-code was a suitable dumping ground. Now there is more than one, we should
do things in a way they are useful to both architectures.
Thanks,
James
^ permalink raw reply
* [RFC PATCH 0/2] New QuadSPI driver for Atmel SAMA5D2
From: Piotr Bugalski @ 2018-06-18 16:21 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Atmel SAMA5D2 is equipped with two QSPI interfaces. These interfaces can
work as in SPI-compatible mode or use two / four lines to improve
communication speed. At the moment there is QSPI driver strongly tied to
NOR-flash memory and MTD subsystem.
Intention of this change is to provide new driver which will not be tied
to MTD and allows using QSPI with NAND-flash memory or other peripherals
New spi-mem API provides abstraction layer which can disconnect QSPI
from MTD. This driver doesn't support regular SPI interface, it should
be used with spi-mem interface only.
Unfortunately SAMA5D2 hardware by default supports only NOR-flash
memory. It allows 24- and 32-bit addressing while NAND-flash requires
16-bit long. To workaround hardware limitation driver is a bit more
complicated.
Request to spi-mem contains three fiels: opcode (command), address,
dummy bytes. SAMA5D2 QSPI hardware supports opcode, address, dummy and
option byte where address field can only be 24- or 32- bytes long.
Handling 8-bits long addresses is done using option field. For 16-bits
address behaviour depends of number of requested dummy bits. If there
are 8 or more dummy cycles, address is shifted and sent with first dummy
byte. Otherwise opcode is disabled and first byte of address contains
command opcode (works only if opcode and address use the same buswidth).
The limitation is when 16-bit address is used without enough dummy
cycles and opcode is using different buswidth than address. Other modes
are supported with described workaround.
It looks like hardware has some limitation in performance. The same issue
exists in current QSPI driver (MTD/nor-flash) and soft-pack (bare-metal
library from Atmel). Without using DMA read speed is much worse than
maximum bandwidth (efficiency 30-40%). Any help with performance
improvement is highly welcome, especially for NAND-flash memories which
offers higher capacity than NOR-flash used with previous driver.
Best Regards,
Piotr
Piotr Bugalski (2):
spi: Add QuadSPI driver for Atmel SAMA5D2
dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation
.../devicetree/bindings/spi/spi_atmel-qspi.txt | 41 ++
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-atmel-qspi.c | 480 +++++++++++++++++++++
4 files changed, 531 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
create mode 100644 drivers/spi/spi-atmel-qspi.c
--
2.11.0
^ permalink raw reply
* [RFC PATCH 1/2] spi: Add QuadSPI driver for Atmel SAMA5D2
From: Piotr Bugalski @ 2018-06-18 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618162124.21749-1-bugalski.piotr@gmail.com>
Kernel contains QSPI driver strongly tied to MTD and nor-flash memory.
New spi-mem interface allows usage also other memory types, especially
much larger NAND with SPI interface. This driver works as SPI controller
and is not related to MTD, however can work with NAND-flash or other
peripherals using spi-mem interface.
Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Piotr Bugalski <pbu@cryptera.com>
---
drivers/spi/Kconfig | 9 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-atmel-qspi.c | 480 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 490 insertions(+)
create mode 100644 drivers/spi/spi-atmel-qspi.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 4a77cfa3213d..4f70a7005997 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -84,6 +84,15 @@ config SPI_ATMEL
This selects a driver for the Atmel SPI Controller, present on
many AT91 ARM chips.
+config SPI_ATMEL_QSPI
+ tristate "Atmel QuadSPI Controller"
+ depends on ARCH_AT91 || (ARM && COMPILE_TEST)
+ depends on OF && HAS_IOMEM
+ help
+ This selects a driver for the Atmel QSPI Controller on SAMA5D2.
+ This controller does not support generic SPI, it supports only
+ spi-mem interface.
+
config SPI_AU1550
tristate "Au1550/Au1200/Au1300 SPI Controller"
depends on MIPS_ALCHEMY
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fe54d787cf4d..6245a5693b16 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST) += spi-loopback-test.o
obj-$(CONFIG_SPI_ALTERA) += spi-altera.o
obj-$(CONFIG_SPI_ARMADA_3700) += spi-armada-3700.o
obj-$(CONFIG_SPI_ATMEL) += spi-atmel.o
+obj-$(CONFIG_SPI_ATMEL_QSPI) += spi-atmel-qspi.o
obj-$(CONFIG_SPI_ATH79) += spi-ath79.o
obj-$(CONFIG_SPI_AU1550) += spi-au1550.o
obj-$(CONFIG_SPI_AXI_SPI_ENGINE) += spi-axi-spi-engine.o
diff --git a/drivers/spi/spi-atmel-qspi.c b/drivers/spi/spi-atmel-qspi.c
new file mode 100644
index 000000000000..1ee626201b0d
--- /dev/null
+++ b/drivers/spi/spi-atmel-qspi.c
@@ -0,0 +1,480 @@
+/*
+ * Atmel SAMA5D2 QuadSPI driver.
+ *
+ * Copyright (C) 2018 Cryptera A/S
+ * All Rights Reserved
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 (GPL v2)
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/spi/spi-mem.h>
+#include <linux/delay.h>
+
+#define QSPI_CR 0x0000
+#define QSPI_MR 0x0004
+#define QSPI_RDR 0x0008
+#define QSPI_TDR 0x000c
+#define QSPI_SR 0x0010
+#define QSPI_IER 0x0014
+#define QSPI_IDR 0x0018
+#define QSPI_IMR 0x001c
+#define QSPI_SCR 0x0020
+
+#define QSPI_IAR 0x0030
+#define QSPI_ICR 0x0034
+#define QSPI_IFR 0x0038
+
+#define QSPI_WPMR 0x00e4
+#define QSPI_WPSR 0x00e8
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN BIT(0)
+#define QSPI_CR_QSPIDIS BIT(1)
+#define QSPI_CR_SWRST BIT(7)
+#define QSPI_CR_LASTXFER BIT(24)
+
+/* Bitfields in QSPI_ICR (Instruction Code Register) */
+#define QSPI_ICR_INST_MASK GENMASK(7, 0)
+#define QSPI_ICR_INST(inst) (((inst) << 0) & QSPI_ICR_INST_MASK)
+#define QSPI_ICR_OPT_MASK GENMASK(23, 16)
+#define QSPI_ICR_OPT(opt) (((opt) << 16) & QSPI_ICR_OPT_MASK)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SMM BIT(0)
+#define QSPI_MR_LLB BIT(1)
+#define QSPI_MR_WDRBT BIT(2)
+#define QSPI_MR_SMRM BIT(3)
+#define QSPI_MR_CSMODE_MASK GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY (2 << 4)
+#define QSPI_MR_NBBITS_MASK GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n) ((((n) - 8) << 8) & QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n) (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK GENMASK(31, 24)
+#define QSPI_MR_DLYCS(n) (((n) << 24) & QSPI_MR_DLYCS_MASK)
+
+/* Bitfields in QSPI_IFR (Instruction Frame Register) */
+#define QSPI_IFR_WIDTH_MASK GENMASK(2, 0)
+#define QSPI_IFR_WIDTH_SINGLE_BIT_SPI (0 << 0)
+#define QSPI_IFR_WIDTH_DUAL_OUTPUT (1 << 0)
+#define QSPI_IFR_WIDTH_QUAD_OUTPUT (2 << 0)
+#define QSPI_IFR_WIDTH_DUAL_IO (3 << 0)
+#define QSPI_IFR_WIDTH_QUAD_IO (4 << 0)
+#define QSPI_IFR_WIDTH_DUAL_CMD (5 << 0)
+#define QSPI_IFR_WIDTH_QUAD_CMD (6 << 0)
+#define QSPI_IFR_INSTEN BIT(4)
+#define QSPI_IFR_ADDREN BIT(5)
+#define QSPI_IFR_OPTEN BIT(6)
+#define QSPI_IFR_DATAEN BIT(7)
+#define QSPI_IFR_OPTL_MASK GENMASK(9, 8)
+#define QSPI_IFR_OPTL_1BIT (0 << 8)
+#define QSPI_IFR_OPTL_2BIT (1 << 8)
+#define QSPI_IFR_OPTL_4BIT (2 << 8)
+#define QSPI_IFR_OPTL_8BIT (3 << 8)
+#define QSPI_IFR_ADDRL BIT(10)
+#define QSPI_IFR_TFRTYP_MASK GENMASK(13, 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ (0 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_READ_MEM (1 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE (2 << 12)
+#define QSPI_IFR_TFRTYP_TRSFR_WRITE_MEM (3 << 13)
+#define QSPI_IFR_CRM BIT(14)
+#define QSPI_IFR_NBDUM_MASK GENMASK(20, 16)
+#define QSPI_IFR_NBDUM(n) (((n) << 16) & QSPI_IFR_NBDUM_MASK)
+
+/* Bitfields in QSPI_SR/QSPI_IER/QSPI_IDR/QSPI_IMR */
+#define QSPI_SR_RDRF BIT(0)
+#define QSPI_SR_TDRE BIT(1)
+#define QSPI_SR_TXEMPTY BIT(2)
+#define QSPI_SR_OVRES BIT(3)
+#define QSPI_SR_CSR BIT(8)
+#define QSPI_SR_CSS BIT(9)
+#define QSPI_SR_INSTRE BIT(10)
+#define QSPI_SR_QSPIENS BIT(24)
+
+#define QSPI_SR_CMD_COMPLETED (QSPI_SR_INSTRE | QSPI_SR_CSR)
+
+
+/* Bitfields in QSPI_SCR (Serial Clock Register) */
+#define QSPI_SCR_CPOL BIT(0)
+#define QSPI_SCR_CPHA BIT(1)
+#define QSPI_SCR_SCBR_MASK GENMASK(15, 8)
+#define QSPI_SCR_SCBR(n) (((n) << 8) & QSPI_SCR_SCBR_MASK)
+#define QSPI_SCR_DLYBS_MASK GENMASK(23, 16)
+#define QSPI_SCR_DLYBS(n) (((n) << 16) & QSPI_SCR_DLYBS_MASK)
+
+#define QSPI_WPMR_WPKEY_PASSWD (0x515350u << 8)
+
+struct atmel_qspi {
+ struct platform_device *pdev;
+ void __iomem *iobase;
+ void __iomem *ahb_addr;
+ int irq;
+ struct clk *clk;
+ u32 clk_rate;
+ struct completion cmd_done;
+ u32 pending;
+};
+
+struct qspi_mode {
+ u8 cmd_buswidth;
+ u8 addr_buswidth;
+ u8 data_buswidth;
+ u32 config;
+};
+
+static const struct qspi_mode sama5d2_qspi_modes[] = {
+ { 1, 1, 1, QSPI_IFR_WIDTH_SINGLE_BIT_SPI },
+ { 1, 1, 2, QSPI_IFR_WIDTH_DUAL_OUTPUT },
+ { 1, 1, 4, QSPI_IFR_WIDTH_QUAD_OUTPUT },
+ { 1, 2, 2, QSPI_IFR_WIDTH_DUAL_IO },
+ { 1, 4, 4, QSPI_IFR_WIDTH_QUAD_IO },
+ { 2, 2, 2, QSPI_IFR_WIDTH_DUAL_CMD },
+ { 4, 4, 4, QSPI_IFR_WIDTH_QUAD_CMD },
+};
+
+static inline u32 qspi_readl(struct atmel_qspi *aq, u32 reg)
+{
+ return readl_relaxed(aq->iobase + reg);
+}
+
+static inline void qspi_writel(struct atmel_qspi *aq, u32 reg, u32 value)
+{
+ writel_relaxed(value, aq->iobase + reg);
+}
+
+static int atmel_qspi_init(struct atmel_qspi *aq)
+{
+ unsigned long rate;
+ u32 scbr;
+
+ qspi_writel(aq, QSPI_WPMR, QSPI_WPMR_WPKEY_PASSWD);
+
+ /* software reset */
+ qspi_writel(aq, QSPI_CR, QSPI_CR_SWRST);
+
+ /* set QSPI mode */
+ qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
+
+ rate = clk_get_rate(aq->clk);
+ if (!rate)
+ return -EINVAL;
+
+ /* set baudrate */
+ scbr = DIV_ROUND_UP(rate, aq->clk_rate);
+ if (scbr > 0)
+ scbr--;
+ qspi_writel(aq, QSPI_SCR, QSPI_SCR_SCBR(scbr));
+
+ /* enable qspi controller */
+ qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIEN);
+
+ return 0;
+}
+
+static int atmel_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+ return 0;
+}
+
+static inline bool is_compatible(const struct spi_mem_op *op,
+ const struct qspi_mode *mode)
+{
+ if (op->cmd.buswidth != mode->cmd_buswidth)
+ return false;
+ if (op->addr.nbytes && op->addr.buswidth != mode->addr_buswidth)
+ return false;
+ if (op->data.nbytes && op->data.buswidth != mode->data_buswidth)
+ return false;
+ return true;
+}
+
+static int find_mode(const struct spi_mem_op *op)
+{
+ u32 i;
+
+ for (i = 0; i < ARRAY_SIZE(sama5d2_qspi_modes); i++)
+ if (is_compatible(op, &sama5d2_qspi_modes[i]))
+ return i;
+ return -1;
+}
+
+static bool atmel_qspi_supports_op(struct spi_mem *mem,
+ const struct spi_mem_op *op)
+{
+ if (find_mode(op) < 0)
+ return false;
+
+ // special case not supported by hardware
+ if ((op->addr.nbytes == 2) && (op->cmd.buswidth != op->addr.buswidth) &&
+ (op->dummy.nbytes == 0))
+ return false;
+
+ return true;
+}
+
+static irqreturn_t atmel_qspi_interrupt(int irq, void *dev_id)
+{
+ struct spi_controller *ctrl = dev_id;
+ struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
+ u32 status, mask, pending;
+
+ status = qspi_readl(aq, QSPI_SR);
+ mask = qspi_readl(aq, QSPI_IMR);
+ pending = status & mask;
+
+ if (!pending)
+ return IRQ_NONE;
+
+ aq->pending |= pending;
+ if ((aq->pending & QSPI_SR_CMD_COMPLETED) == QSPI_SR_CMD_COMPLETED)
+ complete(&aq->cmd_done);
+
+ return IRQ_HANDLED;
+}
+
+static int atmel_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+ struct atmel_qspi *aq = spi_controller_get_devdata(mem->spi->master);
+ int mode;
+ u32 addr = 0;
+ u32 dummy_cycles = 0;
+ u32 ifr = QSPI_IFR_INSTEN;
+ u32 icr = QSPI_ICR_INST(op->cmd.opcode);
+
+ qspi_writel(aq, QSPI_MR, QSPI_MR_SMM);
+
+ mode = find_mode(op);
+ if (mode < 0)
+ return -1;
+ ifr |= sama5d2_qspi_modes[mode].config;
+
+ if (op->dummy.buswidth && op->dummy.nbytes)
+ dummy_cycles = op->dummy.nbytes * 8 / op->dummy.buswidth;
+
+ if (op->addr.buswidth) {
+ switch (op->addr.nbytes) {
+ case 0:
+ break;
+ case 1:
+ ifr |= QSPI_IFR_OPTEN | QSPI_IFR_OPTL_8BIT;
+ icr |= QSPI_ICR_OPT(op->addr.val & 0xff);
+ break;
+ case 2:
+ if (dummy_cycles < 8 / op->addr.buswidth) {
+ ifr &= ~QSPI_IFR_INSTEN;
+ addr = (op->cmd.opcode << 16) |
+ (op->addr.val & 0xffff);
+ ifr |= QSPI_IFR_ADDREN;
+ } else {
+ addr = (op->addr.val << 8) & 0xffffff;
+ dummy_cycles -= 8 / op->addr.buswidth;
+ ifr |= QSPI_IFR_ADDREN;
+ }
+ break;
+ case 3:
+ addr = op->addr.val & 0xffffff;
+ ifr |= QSPI_IFR_ADDREN;
+ break;
+ case 4:
+ addr = op->addr.val;
+ ifr |= QSPI_IFR_ADDREN | QSPI_IFR_ADDRL;
+ break;
+ default:
+ return -1;
+ }
+ }
+ ifr |= QSPI_IFR_NBDUM(dummy_cycles);
+ if (op->data.nbytes == 0)
+ qspi_writel(aq, QSPI_IAR, addr);
+ else
+ ifr |= QSPI_IFR_DATAEN;
+
+ if ((op->data.dir == SPI_MEM_DATA_IN) && (op->data.nbytes > 0))
+ ifr |= QSPI_IFR_TFRTYP_TRSFR_READ;
+ else
+ ifr |= QSPI_IFR_TFRTYP_TRSFR_WRITE;
+
+ qspi_writel(aq, QSPI_IAR, addr);
+ qspi_writel(aq, QSPI_ICR, icr);
+ qspi_writel(aq, QSPI_IFR, ifr);
+ qspi_readl(aq, QSPI_IFR);
+
+ if (op->data.nbytes > 0) {
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ _memcpy_fromio(op->data.buf.in,
+ aq->ahb_addr + addr, op->data.nbytes);
+ else
+ _memcpy_toio(aq->ahb_addr + addr,
+ op->data.buf.out, op->data.nbytes);
+
+ qspi_writel(aq, QSPI_CR, QSPI_CR_LASTXFER);
+ }
+
+ aq->pending = qspi_readl(aq, QSPI_SR) & QSPI_SR_CMD_COMPLETED;
+ if (aq->pending == QSPI_SR_CMD_COMPLETED)
+ return 0;
+ reinit_completion(&aq->cmd_done);
+ qspi_writel(aq, QSPI_IER, QSPI_SR_CMD_COMPLETED);
+ wait_for_completion(&aq->cmd_done);
+ qspi_writel(aq, QSPI_IDR, QSPI_SR_CMD_COMPLETED);
+
+ return 0;
+}
+
+static const struct spi_controller_mem_ops atmel_qspi_mem_ops = {
+ .adjust_op_size = atmel_qspi_adjust_op_size,
+ .supports_op = atmel_qspi_supports_op,
+ .exec_op = atmel_qspi_exec_op
+};
+
+static int atmel_qspi_probe(struct platform_device *pdev)
+{
+ struct spi_controller *ctrl;
+ struct atmel_qspi *aq;
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *child;
+ struct resource *res;
+ int irq, err = 0;
+
+ ctrl = spi_alloc_master(&pdev->dev, sizeof(*aq));
+ if (!ctrl)
+ return -ENOMEM;
+
+ ctrl->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_DUAL | SPI_TX_QUAD;
+ ctrl->bus_num = -1;
+ ctrl->mem_ops = &atmel_qspi_mem_ops;
+ ctrl->num_chipselect = 1;
+ ctrl->dev.of_node = pdev->dev.of_node;
+ platform_set_drvdata(pdev, ctrl);
+
+ aq = spi_controller_get_devdata(ctrl);
+
+ if (of_get_child_count(np) != 1)
+ return -ENODEV;
+ child = of_get_next_child(np, NULL);
+
+ aq->pdev = pdev;
+
+ /* map registers */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_base");
+ aq->iobase = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(aq->iobase)) {
+ dev_err(&pdev->dev, "missing registers\n");
+ err = PTR_ERR(aq->iobase);
+ goto err_put_ctrl;
+ }
+
+ /* map AHB memory */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "qspi_mmap");
+ aq->ahb_addr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(aq->ahb_addr)) {
+ dev_err(&pdev->dev, "missing AHB memory\n");
+ err = PTR_ERR(aq->ahb_addr);
+ goto err_put_ctrl;
+ }
+
+ /* get peripheral clock */
+ aq->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(aq->clk)) {
+ dev_err(&pdev->dev, "missing peripheral clock\n");
+ err = PTR_ERR(aq->clk);
+ goto err_put_ctrl;
+ }
+
+ err = clk_prepare_enable(aq->clk);
+ if (err) {
+ dev_err(&pdev->dev, "failed to enable peripheral clock\n");
+ goto err_put_ctrl;
+ }
+
+ /* request IRQ */
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "missing IRQ\n");
+ err = irq;
+ goto disable_clk;
+ }
+ err = devm_request_irq(&pdev->dev, irq, atmel_qspi_interrupt, 0,
+ dev_name(&pdev->dev), ctrl);
+ if (err)
+ goto disable_clk;
+
+ err = of_property_read_u32(child, "spi-max-frequency", &aq->clk_rate);
+ if (err < 0)
+ goto disable_clk;
+
+ init_completion(&aq->cmd_done);
+
+ err = atmel_qspi_init(aq);
+ if (err)
+ goto disable_clk;
+
+ of_node_put(child);
+
+ err = spi_register_controller(ctrl);
+ if (err)
+ goto disable_clk;
+
+ return 0;
+
+disable_clk:
+ clk_disable_unprepare(aq->clk);
+err_put_ctrl:
+ spi_controller_put(ctrl);
+ of_node_put(child);
+ return err;
+}
+
+static int atmel_qspi_remove(struct platform_device *pdev)
+{
+ struct spi_controller *ctrl = platform_get_drvdata(pdev);
+ struct atmel_qspi *aq = spi_controller_get_devdata(ctrl);
+
+ qspi_writel(aq, QSPI_CR, QSPI_CR_QSPIDIS);
+ clk_disable_unprepare(aq->clk);
+
+ spi_unregister_controller(ctrl);
+
+ return 0;
+}
+
+static const struct of_device_id atmel_qspi_dt_ids[] = {
+ {
+ .compatible = "atmel,sama5d2-spi-qspi"
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, atmel_qspi_dt_ids);
+
+static struct platform_driver atmel_qspi_driver = {
+ .driver = {
+ .name = "atmel_spi_qspi",
+ .of_match_table = atmel_qspi_dt_ids
+ },
+ .probe = atmel_qspi_probe,
+ .remove = atmel_qspi_remove
+};
+
+module_platform_driver(atmel_qspi_driver);
+
+
+MODULE_DESCRIPTION("Atmel SAMA5D2 QuadSPI Driver");
+MODULE_AUTHOR("Piotr Bugalski <pbu@cryptera.com");
+MODULE_LICENSE("GPL v2");
+
--
2.11.0
^ permalink raw reply related
* [RFC PATCH 2/2] dt-bindings: spi: QuadSPI driver for Atmel SAMA5D2 documentation
From: Piotr Bugalski @ 2018-06-18 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618162124.21749-1-bugalski.piotr@gmail.com>
Documentation for DT-binding change.
Suggested-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Piotr Bugalski <pbu@cryptera.com>
---
.../devicetree/bindings/spi/spi_atmel-qspi.txt | 41 ++++++++++++++++++++++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
diff --git a/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
new file mode 100644
index 000000000000..d52b534c9c2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_atmel-qspi.txt
@@ -0,0 +1,41 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible: Should be "atmel,sama5d2-spi-qspi".
+- reg: Should contain the locations and lengths of the base registers
+ and the mapped memory.
+- reg-names: Should contain the resource reg names:
+ - qspi_base: configuration register address space
+ - qspi_mmap: memory mapped address space
+- interrupts: Should contain the interrupt for the device.
+- clocks: The phandle of the clock needed by the QSPI controller.
+- #address-cells: Should be <1>.
+- #size-cells: Should be <0>.
+
+Example:
+
+qspi1: spi at f0024000 {
+ compatible = "atmel,sama5d2-spi-qspi";
+ reg = <0xf0024000 0x100>, <0xd8000000 0x08000000>;
+ reg-names = "qspi_base", "qspi_mmap";
+ interrupts = <53 IRQ_TYPE_LEVEL_HIGH 7>;
+ clocks = <&qspi1_clk>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi1_default>;
+ status = "okay";
+
+ flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "winbond,w25m02gv", "spi-nand";
+ reg = <0>;
+ spi-max-frequency = <83000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <4>;
+
+ ...
+ };
+};
+
--
2.11.0
^ permalink raw reply related
* [PATCH] ARM: dts: imx6: RIoTboard Add chosen stdout-path property
From: Emmanuel Vadot @ 2018-06-18 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529337797.7211.4.camel@pengutronix.de>
On Mon, 18 Jun 2018 18:03:17 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:
> Am Montag, den 18.06.2018, 17:42 +0200 schrieb Emmanuel Vadot:
> > The RIoTboard debug uart is connected to serial1.
> > Add a chosen property in the DTS so OS knows what serial port to use for
> > the console.
> >
> > > Signed-off-by: Emmanuel Vadot <manu@freebsd.org>
> > ---
> > ?arch/arm/boot/dts/imx6dl-riotboard.dts | 4 ++++
> > ?1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts
> > index 2e98c92adff7..315d2ae6fa45 100644
> > --- a/arch/arm/boot/dts/imx6dl-riotboard.dts
> > +++ b/arch/arm/boot/dts/imx6dl-riotboard.dts
> > @@ -19,6 +19,10 @@
> > > ? reg = <0x10000000 0x40000000>;
> > > ? };
> > ?
> > > + chosen {
> > + stdout-path = "serial1:115200n8";
>
> If there a reason to deviate from the "stdout-path = &uart1;" notation
> used by other i.MX boards?
>
> Regards,
> Lucas
This is, AFAIK, the proper way to specify the stdout-path.
See
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/chosen.txt#L31
Cheers,
> > + };
> > +
> > > ? regulators {
> > > ? compatible = "simple-bus";
> > > ? #address-cells = <1>;
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-sdb: Remove duplicate regulator-can2-3v3
From: Fabio Estevam @ 2018-06-18 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abacbb7485b0c9b908eae8ae87be9d8e0eab87b3.1529327283.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 10:11 AM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking at schematics it is indeed gpio2 14 connected to the STB pin of
> the CAN transceiver so remove the first definition.
>
> The second definition entirely overrides the first so this already
> worked and this patch results in no DTB change, just a cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH 1/3] ARM: dts: NSP: Fix i2c controller interrupt type
From: Florian Fainelli @ 2018-06-18 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-2-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:12 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c controller should use IRQ_TYPE_LEVEL_HIGH instead of
> IRQ_TYPE_NONE.
>
> Fixes: 0f9f27a36d09 ("ARM: dts: NSP: Add I2C support to the DT")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 2/3] ARM: dts: NSP: Fix PCIe controllers interrupt types
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-3-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:13 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The interrupts for the PCIe controllers should all be of type
> IRQ_TYPE_LEVEL_HIGH instead of IRQ_TYPE_NONE.
>
> Fixes: d71eb9412088 ("ARM: dts: NSP: Add MSI support on PCI")
> Fixes: 522199029fdc ("ARM: dts: NSP: Fix PCIE DT issue")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 3/3] ARM: dts: HR2: Fix interrupt types for i2c and PCIe
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611224714.7007-4-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:47:14 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c and PCIe controllers had an incorrect type which should have
> been set to IRQ_TYPE_LEVEL_HIGH, fix that.
>
> Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: BCM5301x: Fix i2c controller interrupt type
From: Florian Fainelli @ 2018-06-18 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180611225340.12733-1-f.fainelli@gmail.com>
On Mon, 11 Jun 2018 15:53:40 -0700, Florian Fainelli <f.fainelli@gmail.com> wrote:
> The i2c controller should be using IRQ_TYPE_LEVEL_HIGH, fix that.
>
> Fixes: bb097e3e0045 ("ARM: dts: BCM5301X: Add I2C support to the DT")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
Applied to devicetree/fixes, thanks!
--
Florian
^ permalink raw reply
* [PATCH 0/5] Fix Cygnus, NS2, Stingray interrupt type
From: Florian Fainelli @ 2018-06-18 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528834891-17807-1-git-send-email-ray.jui@broadcom.com>
On 06/12/2018 01:21 PM, Ray Jui wrote:
> This patch series fixes incorrect interrupt types for I2C and PCIe in DT
> for Broadcom Cygnus, NS2, and Stingray SoCs
>
> This patch series is based off v4.17 and is available on GIHUB:
> repo: https://github.com/Broadcom/arm64-linux.git
> branch: cygnus-ns2-dt-irq-type-fix-v1
Series applied to:
- 1&2: devicetree/fixes
- 3-5: devicetree-arm64/fixes
Thanks Ray.
--
Florian
^ permalink raw reply
* [PATCH] arm64: make secondary_start_kernel() notrace
From: Catalin Marinas @ 2018-06-18 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528794457-14129-1-git-send-email-zhizhouzhang@asrmicro.com>
On Tue, Jun 12, 2018 at 05:07:37PM +0800, Zhizhou Zhang wrote:
> We can't call function trace hook before setup percpu offset.
> When entering secondary_start_kernel(), percpu offset has not
> been initialized. So this lead hotplug malfunction.
> Here is the flow to reproduce this bug:
>
> echo 0 > /sys/devices/system/cpu/cpu1/online
> echo function > /sys/kernel/debug/tracing/current_tracer
> echo 1 > /sys/kernel/debug/tracing/tracing_on
> echo 1 > /sys/devices/system/cpu/cpu1/online
>
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@asrmicro.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH v3] ARM: dts: BCM5301X: Add support for Linksys EA9500
From: Vivek Unune @ 2018-06-18 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180222223844.98527-1-npcomplete13@gmail.com>
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
DDR3 RAM - 256 MB
Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
2.4GHz - BCM4366 4?4 2.4/5G single chip 802.11ac SoC
Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
5GHz x 2 - BCM4366 4?4 2.4/5G single chip 802.11ac SoC
Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
Ports - 8 Ports, 1 WAN Ports
Antennas - 8 Antennas
Serial Port - @J6 [GND,TX,RX] (VCC NC) 115200 8n1
Tested with OpenWrt built with DSA driver and Kernel v4.14
Signed-off-by: Vivek Unune <npcomplete13@gmail.com>
---
Changes in v3:
- Remove unnecessary change to BCH settings
- Remove ports 5 & 7 from internal switch for now
Changes in v2:
- Properly define mdio mux, internal mdio, external mdio, mii bus
- Now we define usb3 phy as a mdio node connected to internal mdio,
thanks to work done by Rafa? Mi?ecki on the bcm usb3 phy mdio driver
- Define external SW as a mdio-mii node connected to external mdio
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 225 ++++++++++++++++++++++++
1 file changed, 225 insertions(+)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index 1b26f0be2382..f4f40fd7fbe5 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -31,6 +31,231 @@
linux,code = <KEY_WPS_BUTTON>;
gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
};
+
+ rfkill {
+ label = "WiFi";
+ linux,code = <KEY_RFKILL>;
+ gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
+ };
+
+ reset {
+ label = "Reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wps {
+ label = "bcm53xx:white:wps";
+ gpios = <&chipcommon 22 GPIO_ACTIVE_LOW>;
+ };
+
+ usb2 {
+ label = "bcm53xx:green:usb2";
+ gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port2>, <&ehci_port2>;
+ linux,default-trigger = "usbport";
+ };
+
+ usb3 {
+ label = "bcm53xx:green:usb3";
+ gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port1>, <&ehci_port1>,
+ <&xhci_port1>;
+ linux,default-trigger = "usbport";
+ };
+
+ power {
+ label = "bcm53xx:white:power";
+ gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi-disabled {
+ label = "bcm53xx:amber:wifi-disabled";
+ gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-enabled {
+ label = "bcm53xx:white:wifi-enabled";
+ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar1 {
+ label = "bcm53xx:white:bluebar1";
+ gpios = <&chipcommon 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar2 {
+ label = "bcm53xx:white:bluebar2";
+ gpios = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar3 {
+ label = "bcm53xx:white:bluebar3";
+ gpios = <&chipcommon 15 GPIO_ACTIVE_LOW>;
+ };
+
+ bluebar4 {
+ label = "bcm53xx:white:bluebar4";
+ gpios = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar5 {
+ label = "bcm53xx:white:bluebar5";
+ gpios = <&chipcommon 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar6 {
+ label = "bcm53xx:white:bluebar6";
+ gpios = <&chipcommon 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar7 {
+ label = "bcm53xx:white:bluebar7";
+ gpios = <&chipcommon 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar8 {
+ label = "bcm53xx:white:bluebar8";
+ gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ mdio-bus-mux {
+ mdio_ext: mdio at 200 { /* BIT(9) = 1 => external mdio */
+ reg = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ mdio-mii-mux {
+ compatible = "mdio-mux-mmioreg";
+ mdio-parent-bus = <&mdio_ext>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1800c1c0 0x4>;
+ mux-mask = <0xc0>; /* BIT(6) = mdc, BIT(7) = mdio */
+
+ mdio-mii at 0 {
+ reg = <0x0>; /* Enable mii function */
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch at 0 {
+ compatible = "brcm,bcm53125";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
+ reset-names = "robo_reset";
+ reg = <0>;
+ dsa,member = <1 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port at 1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan6";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "lan3";
+ };
+
+ sw1_p8: port at 8 {
+ reg = <8>;
+ ethernet = <&sw0_p0>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+ };
+ };
+};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
+};
+
+&srab {
+ compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
+ status = "okay";
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 1 {
+ reg = <1>;
+ label = "lan7";
+ };
+
+ port at 2 {
+ reg = <2>;
+ label = "lan4";
+ };
+
+ port at 3 {
+ reg = <3>;
+ label = "lan8";
+ };
+
+ port at 4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port at 8 {
+ reg = <8>;
+ ethernet = <&gmac2>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ sw0_p0: port at 0 {
+ reg = <0>;
+ label = "extsw";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
};
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: exynos: Remove leading 0x from unit addresses in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 17:42 UTC (permalink / raw)
To: linux-arm-kernel
Remove leading 0x from recently introduced unit addresses to fix DTC
warnings:
Warning (unit_address_format): /soc/sysmmu at 0x15040000: unit name should not have leading "0x"
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 038c99792ccb..3a9b4c4b9c63 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -1171,7 +1171,7 @@
power-domains = <&pd_gscl>;
};
- sysmmu_scaler_0: sysmmu at 0x15040000 {
+ sysmmu_scaler_0: sysmmu at 15040000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x15040000 0x1000>;
interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>;
@@ -1182,7 +1182,7 @@
power-domains = <&pd_mscl>;
};
- sysmmu_scaler_1: sysmmu at 0x15050000 {
+ sysmmu_scaler_1: sysmmu at 15050000 {
compatible = "samsung,exynos-sysmmu";
reg = <0x15050000 0x1000>;
interrupts = <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Krzysztof Kozlowski @ 2018-06-18 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-1-krzk@kernel.org>
The decon, decon_tv and dsi nodes have only one child port so
address/size mappings are not necessary. This fixes DTC warnings like:
Warning (graph_child_address): /soc/decon at 13800000/ports:
graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
2 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index a1e3194b7483..0a15ee513f5c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -321,11 +321,7 @@
status = "okay";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
tv_to_hdmi: endpoint {
remote-endpoint = <&hdmi_to_tv>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3a9b4c4b9c63..e4367fd39120 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -850,11 +850,7 @@
iommu-names = "m0", "m1";
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
decon_to_mic: endpoint {
remote-endpoint =
<&mic_to_decon>;
@@ -914,11 +910,7 @@
#size-cells = <0>;
ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 0 {
- reg = <0>;
+ port {
dsi_to_mic: endpoint {
remote-endpoint = <&mic_to_dsi>;
};
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox