* [GIT PULL] tee dynamic shm for v4.16
From: thomas zeng @ 2017-12-25 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a09za3vGW5P5xDExurTtB=s8adcvz_m-czrE4cZcorGmg@mail.gmail.com>
On 2017?12?21? 08:30, Arnd Bergmann wrote:
> On Fri, Dec 15, 2017 at 2:21 PM, Jens Wiklander
> <jens.wiklander@linaro.org> wrote:
>> Hello arm-soc maintainers,
>>
>> Please pull these tee driver changes. This implements support for dynamic
>> shared memory support in OP-TEE. More specifically is enables mapping of
>> user space memory in secure world to be used as shared memory.
>>
>> This has been reviewed and refined by the OP-TEE community at various
>> places on Github during the last year. An earlier version of this pull
>> request is used in the latest OP-TEE release (2.6.0). This has also been
>> reviewed recently at the kernel mailing lists, with all comments from
>> Mark Rutland <mark.rutland@arm.com> and Yury Norov
>> <ynorov@caviumnetworks.com> addressed as far as I can tell.
>>
>> This isn't a bugfix so I'm aiming for the next merge window.
> Given that Mark and Yury reviewed this, I'm assuming this is all
> good and have now merged it. However I missed the entire discussion
> about it, so I have one question about the implementation:
>
> What happens when user space passes a buffer that is not
> backed by regular memory but instead is something it has itself
> mapped from a device with special page attributes or physical
> properties? Could this be inconsistent when optee and user
> space disagree on the caching attributes? Can you get into
> trouble if you pass an area from a device that is read-only
> in user space but writable from secure world?
Just recently, we have started to kick the tires of these "shm" related
Gen Tee Driver patches.? And we have in the past encountered real world
scenarios requiring some of the shared memory regions to be marked as
"normal IC=0 and OC=0" in EL2 or SEL1, or else HW would misbehave. We
worked around by hacking the boot code but that works if the regions are
pre-allocated. Since now these regions can also be managed dynamically,
we definitely agree with Arnd Bergmann that the dynamic registration SMC
commands, and potention the SHM IOCTL commands, must convey cache
intentions. Is it possible to take this requirement into consideration,
in this iteration or the follow on?
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [patch v15 1/4] drivers: jtag: Add JTAG core driver
From: Florian Fainelli @ 2017-12-25 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514202808-29747-2-git-send-email-oleksandrs@mellanox.com>
Le 12/25/17 ? 03:53, Oleksandr Shamray a ?crit?:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices which equipped with JTAG interface
> using standard transactions.
>
> Driver exposes set of IOCTL to user space for:
> - XFER:
> - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
> - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
> - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> number of clocks).
> - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.
>
> Driver core provides set of internal APIs for allocation and
> registration:
> - jtag_register;
> - jtag_unregister;
> - jtag_alloc;
> - jtag_free;
>
> Platform driver on registration with jtag-core creates the next
> entry in dev folder:
> /dev/jtagX
Just some general comment, I am really surprised to see that there is
not a whole lot of generic code, actually, there is none, which tries to
manage the JTAG devices command queue, e.g: ala OpenOCD. All that this
is doing here is create a special character device with a bunch of
custom ioctl(), which means that a lot of code is going to be put within
in individual drivers. Have you given some thoughts on how you would
expand this framework for non ASPEED JTAG adapters? For instance, one
expectation is to see a bit-banged GPIO master, since that's quite
common, what would it look like here? How much code would I have to write?
[snip]
> +
> +void *jtag_priv(struct jtag *jtag)
> +{
> + return jtag->priv;
> +}
> +EXPORT_SYMBOL_GPL(jtag_priv);
Can't you just create a static inline function in the public header for
that? This is usually what subsystems do, I can understand why you would
not want to expose struct jtag to other parts of the kernel, but still,
this looks ugly, so maybe consider splitting the header between provider
and consumer?
> +
> +static long jtag_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> + struct jtag *jtag = file->private_data;
> + struct jtag_run_test_idle idle;
> + struct jtag_xfer xfer;
> + u8 *xfer_data;
> + u32 data_size;
> + u32 value;
> + int err;
> +
> + if (!arg)
> + return -EINVAL;
> +
> + switch (cmd) {
> + case JTAG_GIOCFREQ:
> +
> + if (jtag->ops->freq_get)
> + err = jtag->ops->freq_get(jtag, &value);
> + else
> + err = -EOPNOTSUPP;
> + if (err)
> + break;
> +
> + if (put_user(value, (__u32 *)arg))
> + err = -EFAULT;
> + break;
> +
> + case JTAG_SIOCFREQ:
> + if (get_user(value, (__u32 *)arg))
> + return -EFAULT;
> + if (value == 0)
> + return -EINVAL;
> +
> + if (jtag->ops->freq_set)
> + err = jtag->ops->freq_set(jtag, value);
> + else
> + err = -EOPNOTSUPP;
You should check that before get_user()
> + break;
> +
> + case JTAG_IOCRUNTEST:
> + if (copy_from_user(&idle, (void *)arg,
> + sizeof(struct jtag_run_test_idle)))
> + return -EFAULT;
> +
> + if (idle.endstate > JTAG_STATE_PAUSEDR)
> + return -EINVAL;
> +
> + if (jtag->ops->idle)
> + err = jtag->ops->idle(jtag, &idle);
> + else
> + err = -EOPNOTSUPP;
> + break;
Same here.
> +
> + case JTAG_IOCXFER:
> + if (copy_from_user(&xfer, (void *)arg,
> + sizeof(struct jtag_xfer)))
> + return -EFAULT;
> +
> + if (xfer.length >= JTAG_MAX_XFER_DATA_LEN)
> + return -EINVAL;
> +
> + if (xfer.type > JTAG_SDR_XFER)
> + return -EINVAL;
> +
> + if (xfer.direction > JTAG_WRITE_XFER)
> + return -EINVAL;
> +
> + if (xfer.endstate > JTAG_STATE_PAUSEDR)
> + return -EINVAL;
> +
> + data_size = DIV_ROUND_UP(xfer.length, BITS_PER_BYTE);
> + xfer_data = memdup_user(u64_to_user_ptr(xfer.tdio), data_size);
> +
> + if (!xfer_data)
> + return -EFAULT;
> +
> + if (jtag->ops->xfer) {
> + err = jtag->ops->xfer(jtag, &xfer, xfer_data);
> + } else {
> + kfree(xfer_data);
> + return -EOPNOTSUPP;
> + }
Why don't you move all of the code here into a function which will make
the error handling consistent? Also, checking whether the jtag adapter
implements ops->xfer should probably be done before you do the
memdup_user().
> +
> + if (err) {
> + kfree(xfer_data);
> + return -EFAULT;
> + }
> +
> + err = copy_to_user(u64_to_user_ptr(xfer.tdio),
> + (void *)(xfer_data), data_size);
> +
> + if (err) {
> + kfree(xfer_data);
> + return -EFAULT;
> + }
> +
> + kfree(xfer_data);
> + if (copy_to_user((void *)arg, &xfer, sizeof(struct jtag_xfer)))
> + return -EFAULT;
> + break;
> +
> + case JTAG_GIOCSTATUS:
> + if (jtag->ops->status_get)
> + err = jtag->ops->status_get(jtag, &value);
> + else
> + err = -EOPNOTSUPP;
> + if (err)
> + break;
> +
> + err = put_user(value, (__u32 *)arg);
> + if (err)
> + err = -EFAULT;
> + break;
> + case JTAG_SIOCMODE:
> + if (get_user(value, (__u32 *)arg))
> + return -EFAULT;
> + if (value == 0)
> + return -EINVAL;
> +
> + if (jtag->ops->mode_set)
> + err = jtag->ops->mode_set(jtag, value);
> + else
> + err = -EOPNOTSUPP;
> + break;
Same here, this can be checked before get_user().
> +
> + default:
> + return -EINVAL;
> + }
> + return err;
> +}
> +
> +static int jtag_open(struct inode *inode, struct file *file)
> +{
> + struct jtag *jtag = container_of(file->private_data, struct jtag,
> + miscdev);
> +
> + if (mutex_lock_interruptible(&jtag->open_lock))
> + return -ERESTARTSYS;
> +
> + if (jtag->opened) {
> + mutex_unlock(&jtag->open_lock);
> + return -EINVAL;
-EBUSY maybe?
> + }
> +
> + nonseekable_open(inode, file);
> + file->private_data = jtag;
> + jtag->opened = true;
> + mutex_unlock(&jtag->open_lock);
> + return 0;
> +}
> +
> +static int jtag_release(struct inode *inode, struct file *file)
> +{
> + struct jtag *jtag = file->private_data;
> +
> + mutex_lock(&jtag->open_lock);
> + jtag->opened = false;
> + mutex_unlock(&jtag->open_lock);
> + return 0;
> +}
> +
> +static const struct file_operations jtag_fops = {
> + .owner = THIS_MODULE,
> + .open = jtag_open,
> + .release = jtag_release,
> + .llseek = noop_llseek,
> + .unlocked_ioctl = jtag_ioctl,
> +};
> +
> +struct jtag *jtag_alloc(size_t priv_size, const struct jtag_ops *ops)
> +{
> + struct jtag *jtag;
> +
> + jtag = kzalloc(sizeof(*jtag) + round_up(priv_size, ARCH_DMA_MINALIGN),
> + GFP_KERNEL);
> + if (!jtag)
> + return NULL;
If you set ARCH_DMA_MINALIGN to 1 when not defined, what is this
achieving that kmalloc() is not already doing?
> +
> + jtag->ops = ops;
> + return jtag;
> +}
> +EXPORT_SYMBOL_GPL(jtag_alloc);
> +
> +void jtag_free(struct jtag *jtag)
> +{
> + kfree(jtag);
> +}
> +EXPORT_SYMBOL_GPL(jtag_free);
> +
> +int jtag_register(struct jtag *jtag)
> +{
> + char *name;
> + int err;
> + int id;
> +
> + id = ida_simple_get(&jtag_ida, 0, 0, GFP_KERNEL);
> + if (id < 0)
> + return id;
> +
> + jtag->id = id;
> +
> + name = kzalloc(MAX_JTAG_NAME_LEN, GFP_KERNEL);
> + if (!name) {
> + err = -ENOMEM;
> + goto err_jtag_alloc;
> + }
Can't you use jtag->miscdev.dev here to simplify the allocation error
handling?
> +
> + err = snprintf(name, MAX_JTAG_NAME_LEN, "jtag%d", id);
> + if (err < 0)
> + goto err_jtag_name;
> +
> + mutex_init(&jtag->open_lock);
> + jtag->miscdev.fops = &jtag_fops;
> + jtag->miscdev.minor = MISC_DYNAMIC_MINOR;
> + jtag->miscdev.name = name;
> +
> + err = misc_register(&jtag->miscdev);
> + if (err)
> + dev_err(jtag->dev, "Unable to register device\n");
> + else
> + return 0;
> + jtag->opened = false;
> +
> +err_jtag_name:
> + kfree(name);
> +err_jtag_alloc:
> + ida_simple_remove(&jtag_ida, id);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(jtag_register);
> +
> +void jtag_unregister(struct jtag *jtag)
> +{
> + misc_deregister(&jtag->miscdev);
> + kfree(jtag->miscdev.name);
> + ida_simple_remove(&jtag_ida, jtag->id);
> +}
> +EXPORT_SYMBOL_GPL(jtag_unregister);
> +
> +static void __exit jtag_exit(void)
> +{
> + ida_destroy(&jtag_ida);
> +}
> +
> +module_exit(jtag_exit);
> +
> +MODULE_AUTHOR("Oleksandr Shamray <oleksandrs@mellanox.com>");
> +MODULE_DESCRIPTION("Generic jtag support");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/jtag.h b/include/linux/jtag.h
> new file mode 100644
> index 0000000..312c641
> --- /dev/null
> +++ b/include/linux/jtag.h
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// include/linux/jtag.h - JTAG class driver
> +//
> +// Copyright (c) 2017 Mellanox Technologies. All rights reserved.
> +// Copyright (c) 2017 Oleksandr Shamray <oleksandrs@mellanox.com>
> +
> +#ifndef __JTAG_H
> +#define __JTAG_H
> +
> +#include <uapi/linux/jtag.h>
> +
> +#ifndef ARCH_DMA_MINALIGN
> +#define ARCH_DMA_MINALIGN 1
> +#endif
Why?
> +
> +#define jtag_u64_to_ptr(arg) ((void *)(uintptr_t)arg)
> +
> +#define JTAG_MAX_XFER_DATA_LEN 65535
> +
> +struct jtag;
> +/**
> + * struct jtag_ops - callbacks for jtag control functions:
> + *
> + * @freq_get: get frequency function. Filled by device driver
> + * @freq_set: set frequency function. Filled by device driver
> + * @status_get: set status function. Filled by device driver
> + * @idle: set JTAG to idle state function. Filled by device driver
> + * @xfer: send JTAG xfer function. Filled by device driver
> + */
> +struct jtag_ops {
> + int (*freq_get)(struct jtag *jtag, u32 *freq);
> + int (*freq_set)(struct jtag *jtag, u32 freq);
> + int (*status_get)(struct jtag *jtag, u32 *state);
> + int (*idle)(struct jtag *jtag, struct jtag_run_test_idle *idle);
> + int (*xfer)(struct jtag *jtag, struct jtag_xfer *xfer, u8 *xfer_data);
> + int (*mode_set)(struct jtag *jtag, u32 mode_mask);
> +};
> +
> +void *jtag_priv(struct jtag *jtag);
> +int jtag_register(struct jtag *jtag);
> +void jtag_unregister(struct jtag *jtag);
> +struct jtag *jtag_alloc(size_t priv_size, const struct jtag_ops *ops);
> +void jtag_free(struct jtag *jtag);
> +
> +#endif /* __JTAG_H */
> diff --git a/include/uapi/linux/jtag.h b/include/uapi/linux/jtag.h
> new file mode 100644
> index 0000000..cda2520
> --- /dev/null
> +++ b/include/uapi/linux/jtag.h
[snip]
> +struct jtag_xfer {
> + __u8 type;
> + __u8 direction;
Can these two be an enum referring to what you defined earlier?
> + __u8 endstate;
> + __u32 length;
> + __u64 tdio;
> +};
--
Florian
^ permalink raw reply
* [patch v15 0/4] JTAG driver introduction
From: Florian Fainelli @ 2017-12-25 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514202808-29747-1-git-send-email-oleksandrs@mellanox.com>
Le 12/25/17 ? 03:53, Oleksandr Shamray a ?crit?:
> When a need raise up to use JTAG interface for system's devices
> programming or CPU debugging, usually the user layer
> application implements jtag protocol by bit-bang or using a
> proprietary connection to vendor hardware.
> This method can be slow and not generic.
>
> We propose to implement general JTAG interface and infrastructure
> to communicate with user layer application. In such way, we can
> have the standard JTAG interface core part and separation from
> specific HW implementation.
Well, the framework in its current shape is still extremely simplistic,
therefore leaving a lot of room (read: bugs, inconsistencies) within the
hands of the driver, so while the user-space interface is standard
through the proposed character device, the user experience, likely might
not.
> This allow new capability to debug the CPU or program system's
> device via BMC without additional devices nor cost.
If that is the case, should not we leverage the kernel's device driver
model and expect the JTAG framework to create specific devices for the
different pieces of HW discovered on the scan chain? That would also
presumably allow the core JTAG framework to retain the necessary state
changes in order to address one particular device within the scan chain.
>
> This patch purpose is to add JTAG master core infrastructure by
> defining new JTAG class and provide generic JTAG interface
> to allow hardware specific drivers to connect this interface.
> This will enable all JTAG drivers to use the common interface
> part and will have separate for hardware implementation.
Let's consider I want to get rid of OpenOCD, or rather, move its driver
interface within the kernel and replace it on the OpenOCD side with a
generic character device interface. I could presumably amortize the
costly operations which are currently I/O and/or system call limiting
when running in user-space, what would it look like with your proposed
framework, have you given some thoughts about that?
Thanks!
--
Florian
^ permalink raw reply
* [linux-sunxi] [PATCH v4 0/2] Initial Allwinner V3s CSI Support
From: Yong @ 2017-12-26 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171225085802.lfyk4blmbqxq6r2m@core.my.home>
On Mon, 25 Dec 2017 09:58:02 +0100
Ond?ej Jirman <megous@megous.com> wrote:
> Hello,
>
> On Mon, Dec 25, 2017 at 11:15:26AM +0800, Yong wrote:
> > Hi,
> >
> > On Fri, 22 Dec 2017 14:46:48 +0100
> > Ond?ej Jirman <megous@megous.com> wrote:
> >
> > > Hello,
> > >
> > > Yong Deng p??e v P? 22. 12. 2017 v 17:32 +0800:
> > > >
> > > > Test input 0:
> > > >
> > > > Control ioctls:
> > > > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> > > > test VIDIOC_QUERYCTRL: OK (Not Supported)
> > > > test VIDIOC_G/S_CTRL: OK (Not Supported)
> > > > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> > > > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> > > > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > > > Standard Controls: 0 Private Controls: 0
> > >
> > > I'm not sure if your driver passes control queries to the subdev. It
> > > did not originally, and I'm not sure you picked up the change from my
> > > version of the driver. "Not supported" here seems to indicate that it
> > > does not.
> > >
> > > I'd be interested what's the recommended practice here. It sure helps
> > > with some apps that expect to be able to modify various input controls
> > > directly on the /dev/video# device. These are then supported out of the
> > > box.
> > >
> > > It's a one-line change. See:
> > >
> > > https://www.kernel.org/doc/html/latest/media/kapi/v4l2-controls.html#in
> > > heriting-controls
> >
> > I think this is a feature and not affect the driver's main function.
> > I just focused on making the CSI main function to work properly in
> > the initial version. Is this feature mandatory or most commonly used?
>
> I grepped the platform/ code and it seems, that inheriting controls
> from subdevs is pretty common for input drivers. (there are varying
> approaches though, some inherit by hand in the link function, some
> just register and empty ctrl_handler on the v4l2_dev and leave the
> rest to the core).
>
> Practically, I haven't found a common app that would allow me to enter
> both /dev/video0 and /dev/v4l-subdevX. I'm sure anyone can write one
> themselves, but it would be better if current controls were available
> at the /dev/video0 device automatically.
>
> It's much simpler for the userspace apps than the alternative, which
> is trying to identify the correct subdev that is currently
> associated with the CSI driver at runtime, which is not exactly
> straightforward and requires much more code, than a few lines in
> the kernel, that are required to inherit controls:
>
>
> ret = v4l2_ctrl_handler_init(&csi->ctrl_handler, 0);
> if (ret) {
> dev_err(csi->dev,
> "V4L2 controls handler init failed (%d)\n",
> ret);
> goto handle_error;
> }
>
> csi->v4l2_dev.ctrl_handler = &csi->ctrl_handler;
>
> See: https://github.com/megous/linux/blob/linux-tbs/drivers/media/platform/sun6i-csi/sun6i_csi.c#L1005
Ok, I will add this. Thanks for your explication.
>
> regards,
> o.j.
>
> > Thanks,
> > Yong
Thanks,
Yong
^ permalink raw reply
* [PATCH 0/2] add has-transaction-translator property to usb node
From: Kunihiko Hayashi @ 2017-12-26 1:03 UTC (permalink / raw)
To: linux-arm-kernel
This series adds has-transaction-translator property to usb node
for each SoC which has usb-ehci host controller.
Kunihiko Hayashi (2):
ARM: dts: uniphier: add has-transaction-translator property to usb
node for LD4, sLD8 and Pro4
arm64: dts: uniphier: add has-transaction-translator property to usb
node for LD11
arch/arm/boot/dts/uniphier-ld4.dtsi | 3 +++
arch/arm/boot/dts/uniphier-pro4.dtsi | 2 ++
arch/arm/boot/dts/uniphier-sld8.dtsi | 3 +++
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 3 +++
4 files changed, 11 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] ARM: dts: uniphier: add has-transaction-translator property to usb node for LD4, sLD8 and Pro4
From: Kunihiko Hayashi @ 2017-12-26 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514250220-925-1-git-send-email-hayashi.kunihiko@socionext.com>
When a full/low speed device is connected to USB 2.0 port on UniPhier SoC
that has ehci controller, the kernel shows the following messages.
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: unable to enumerate USB device
To fix the issue, the driver needs to enable Transaction Translator on ehci
root hub. This adds 'has-transaction-translator' property to each node.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
arch/arm/boot/dts/uniphier-ld4.dtsi | 3 +++
arch/arm/boot/dts/uniphier-pro4.dtsi | 2 ++
arch/arm/boot/dts/uniphier-sld8.dtsi | 3 +++
3 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi b/arch/arm/boot/dts/uniphier-ld4.dtsi
index 01fc3e1..27f0781 100644
--- a/arch/arm/boot/dts/uniphier-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
@@ -235,6 +235,7 @@
<&mio_clk 12>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 8>,
<&mio_rst 12>;
+ has-transaction-translator;
};
usb1: usb at 5a810100 {
@@ -248,6 +249,7 @@
<&mio_clk 13>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 9>,
<&mio_rst 13>;
+ has-transaction-translator;
};
usb2: usb at 5a820100 {
@@ -261,6 +263,7 @@
<&mio_clk 14>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 10>,
<&mio_rst 14>;
+ has-transaction-translator;
};
soc-glue at 5f800000 {
diff --git a/arch/arm/boot/dts/uniphier-pro4.dtsi b/arch/arm/boot/dts/uniphier-pro4.dtsi
index 7955c3a..c346147 100644
--- a/arch/arm/boot/dts/uniphier-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
@@ -269,6 +269,7 @@
<&mio_clk 12>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 8>,
<&mio_rst 12>;
+ has-transaction-translator;
};
usb3: usb at 5a810100 {
@@ -282,6 +283,7 @@
<&mio_clk 13>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 9>,
<&mio_rst 13>;
+ has-transaction-translator;
};
soc-glue at 5f800000 {
diff --git a/arch/arm/boot/dts/uniphier-sld8.dtsi b/arch/arm/boot/dts/uniphier-sld8.dtsi
index 7188536..de28c52 100644
--- a/arch/arm/boot/dts/uniphier-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
@@ -239,6 +239,7 @@
<&mio_clk 12>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 8>,
<&mio_rst 12>;
+ has-transaction-translator;
};
usb1: usb at 5a810100 {
@@ -252,6 +253,7 @@
<&mio_clk 13>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 9>,
<&mio_rst 13>;
+ has-transaction-translator;
};
usb2: usb at 5a820100 {
@@ -265,6 +267,7 @@
<&mio_clk 14>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 10>,
<&mio_rst 14>;
+ has-transaction-translator;
};
soc-glue at 5f800000 {
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: uniphier: add has-transaction-translator property to usb node for LD11
From: Kunihiko Hayashi @ 2017-12-26 1:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514250220-925-1-git-send-email-hayashi.kunihiko@socionext.com>
When a full/low speed device is connected to USB 2.0 port on UniPhier SoC
that has ehci controller, the kernel shows the following messages.
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
| usb usb1-port1: unable to enumerate USB device
To fix the issue, the driver needs to enable Transaction Translator on ehci
root hub. This adds 'has-transaction-translator' property to each node.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 1c63d0a..f8d2635 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -347,6 +347,7 @@
<&mio_clk 12>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 8>,
<&mio_rst 12>;
+ has-transaction-translator;
};
usb1: usb at 5a810100 {
@@ -360,6 +361,7 @@
<&mio_clk 13>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 9>,
<&mio_rst 13>;
+ has-transaction-translator;
};
usb2: usb at 5a820100 {
@@ -373,6 +375,7 @@
<&mio_clk 14>;
resets = <&sys_rst 8>, <&mio_rst 7>, <&mio_rst 10>,
<&mio_rst 14>;
+ has-transaction-translator;
};
mioctrl at 5b3e0000 {
--
2.7.4
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Dave Young @ 2017-12-26 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMzYidDaC0_yfwgVOisH-FqcNViYj+Z54uKfUtHkJKKXA@mail.gmail.com>
On 12/26/17 at 01:44am, Bhupesh Sharma wrote:
> On Mon, Dec 25, 2017 at 8:55 AM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > On Sun, Dec 24, 2017 at 01:21:02AM +0530, Bhupesh Sharma wrote:
> >> On Fri, Dec 22, 2017 at 2:03 PM, AKASHI Takahiro
> >> <takahiro.akashi@linaro.org> wrote:
> >> > On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote:
> >> >> Hello Akashi,
> >> >>
> >> >> On Thu, Dec 21, 2017 at 4:04 PM, AKASHI Takahiro
> >> >> <takahiro.akashi@linaro.org> wrote:
> >> >> > Bhupesh,
> >> >> >
> >> >> > Can you test the patch attached below, please?
> >> >> >
> >> >> > It is intended to retain already-reserved regions (ACPI reclaim memory
> >> >> > in this case) in system ram (i.e. memblock.memory) without explicitly
> >> >> > exporting them via usable-memory-range.
> >> >> > (I still have to figure out what the side-effect of this patch is.)
> >> >> >
> >> >> > Thanks,
> >> >> > -Takahiro AKASHI
> >> >> >
> >> >> > On Thu, Dec 21, 2017 at 01:30:43AM +0530, Bhupesh Sharma wrote:
> >> >> >> On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
> >> >> >> <ard.biesheuvel@linaro.org> wrote:
> >> >> >> > On 19 December 2017 at 07:09, AKASHI Takahiro
> >> >> >> > <takahiro.akashi@linaro.org> wrote:
> >> >> >> >> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
> >> >> >> >>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> >> >> >> >>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> >> >> >>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> >> >> >> >>> > > <takahiro.akashi@linaro.org> wrote:
> >> >> >> >>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> >> >> >>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> >> >> >>> > > >> <takahiro.akashi@linaro.org> wrote:
> >> >> >> >>> > > >> > Bhupesh, Ard,
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >> >> >>> > > >> >> Hi Ard, Akashi
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> > (snip)
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >> >> >>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >> >> >>> > > >> >> identify its own usable memory and exclude, at its boot time, any
> >> >> >> >>> > > >> >> other memory areas that are part of the panicked kernel's memory.
> >> >> >> >>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >> >> >>> > > >> >> , for details)
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> > Right.
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >> >> >>> > > >> >> with the crashkernel memory range:
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> /* add linux,usable-memory-range */
> >> >> >> >>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >> >> >>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >> >> >>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >> >> >>> > > >> >> address_cells, size_cells);
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >> >> >>> > > >> >> , for details)
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >> >> >>> > > >> >> they are marked as System RAM or as RESERVED. As,
> >> >> >> >>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >> >> >>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >> >> >>> > > >> >> ACPI memory and crashes while trying to access the same:
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >> >> >>> > > >> >> -r`.img --reuse-cmdline -d
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> [snip..]
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> Reserved memory range
> >> >> >> >>> > > >> >> 000000000e800000-000000002e7fffff (0)
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> Coredump memory ranges
> >> >> >> >>> > > >> >> 0000000000000000-000000000e7fffff (0)
> >> >> >> >>> > > >> >> 000000002e800000-000000003961ffff (0)
> >> >> >> >>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >> >> >>> > > >> >> 000000003ed60000-000000003fbfffff (0)
> >> >> >> >>> > > >> >> 0000001040000000-0000001ffbffffff (0)
> >> >> >> >>> > > >> >> 0000002000000000-0000002ffbffffff (0)
> >> >> >> >>> > > >> >> 0000009000000000-0000009ffbffffff (0)
> >> >> >> >>> > > >> >> 000000a000000000-000000affbffffff (0)
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >> >> >>> > > >> >> memory cap'ing passed to the crash kernel inside
> >> >> >> >>> > > >> >> 'arch/arm64/mm/init.c' (see below):
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> static void __init fdt_enforce_memory_region(void)
> >> >> >> >>> > > >> >> {
> >> >> >> >>> > > >> >> struct memblock_region reg = {
> >> >> >> >>> > > >> >> .size = 0,
> >> >> >> >>> > > >> >> };
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> if (reg.size)
> >> >> >> >>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >> >> >>> > > >> >> comment this out */
> >> >> >> >>> > > >> >> }
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> > Please just don't do that. It can cause a fatal damage on
> >> >> >> >>> > > >> > memory contents of the *crashed* kernel.
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> >> 5). Both the above temporary solutions fix the problem.
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >> >> >>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >> >> >>> > > >> >> fail.
> >> >> >> >>> > > >> >>
> >> >> >> >>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >> >> >>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >> >> >>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >> >> >>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >> >> >>> > > >> >> dt node 'linux,usable-memory-range'
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >> > I still don't understand why we need to carry over the information
> >> >> >> >>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> >> >> >>> > > >> > such regions are free to be reused by the kernel after some point of
> >> >> >> >>> > > >> > initialization. Why does crash dump kernel need to know about them?
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >>
> >> >> >> >>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> >> >> >> >>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> >> >> >>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> >> >> >> >>> > > >> kernel, those regions needs to be preserved, which is why they are
> >> >> >> >>> > > >> memblock_reserve()'d now.
> >> >> >> >>> > > >
> >> >> >> >>> > > > For my better understandings, who is actually accessing such regions
> >> >> >> >>> > > > during boot time, uefi itself or efistub?
> >> >> >> >>> > > >
> >> >> >> >>> > >
> >> >> >> >>> > > No, only the kernel. This is where the ACPI tables are stored. For
> >> >> >> >>> > > instance, on QEMU we have
> >> >> >> >>> > >
> >> >> >> >>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> >> >> >>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> >> >> >>> > > 01000013)
> >> >> >> >>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> >> >> >>> > > BXPC 00000001)
> >> >> >> >>> > >
> >> >> >> >>> > > covered by
> >> >> >> >>> > >
> >> >> >> >>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> >> >> >>> > > ...
> >> >> >> >>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> >> >> >>> >
> >> >> >> >>> > OK. I mistakenly understood those regions could be freed after exiting
> >> >> >> >>> > UEFI boot services.
> >> >> >> >>> >
> >> >> >> >>> > >
> >> >> >> >>> > > >> So it seems that kexec does not honour the memblock_reserve() table
> >> >> >> >>> > > >> when booting the next kernel.
> >> >> >> >>> > > >
> >> >> >> >>> > > > not really.
> >> >> >> >>> > > >
> >> >> >> >>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> >> >> >> >>> > > >> > on crash dump kernel?)
> >> >> >> >>> > > >> >
> >> >> >> >>> > > >>
> >> >> >> >>> > > >> I don't think so. And the change to the handling of ACPI reclaim
> >> >> >> >>> > > >> regions only revealed the bug, not created it (given that other
> >> >> >> >>> > > >> memblock_reserve regions may be affected as well)
> >> >> >> >>> > > >
> >> >> >> >>> > > > As whether we should honor such reserved regions over kexec'ing
> >> >> >> >>> > > > depends on each one's specific nature, we will have to take care one-by-one.
> >> >> >> >>> > > > As a matter of fact, no information about "reserved" memblocks is
> >> >> >> >>> > > > exposed to user space (via proc/iomem).
> >> >> >> >>> > > >
> >> >> >> >>> > >
> >> >> >> >>> > > That is why I suggested (somewhere in this thread?) to not expose them
> >> >> >> >>> > > as 'System RAM'. Do you think that could solve this?
> >> >> >> >>> >
> >> >> >> >>> > Memblock-reserv'ing them is necessary to prevent their corruption and
> >> >> >> >>> > marking them under another name in /proc/iomem would also be good in order
> >> >> >> >>> > not to allocate them as part of crash kernel's memory.
> >> >> >> >>> >
> >> >> >> >>> > But I'm not still convinced that we should export them in useable-
> >> >> >> >>> > memory-range to crash dump kernel. They will be accessed through
> >> >> >> >>> > acpi_os_map_memory() and so won't be required to be part of system ram
> >> >> >> >>> > (or memblocks), I guess.
> >> >> >> >>> > -> Bhupesh?
> >> >> >> >>>
> >> >> >> >>> I forgot how arm64 kernel retrieve the memory ranges and initialize
> >> >> >> >>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> >> >> >> >>> the memory according to the efi memmap? For kdump kernel anything other
> >> >> >> >>> than usable memory (which is from the dt node instead) should be
> >> >> >> >>> reinitialized according to efi passed info, no?
> >> >> >> >>
> >> >> >> >> All the regions exported in efi memmap will be added to memblock.memory
> >> >> >> >> in (u)efi_init() and then trimmed down to the exact range specified as
> >> >> >> >> usable-memory-range by fdt_enforce_memory_region().
> >> >> >> >>
> >> >> >> >> Now I noticed that the current fdt_enforce_memory_region() may not work well
> >> >> >> >> with multiple entries in usable-memory-range.
> >> >> >> >>
> >> >> >> >
> >> >> >> > In any case, the root of the problem is that memory regions lose their
> >> >> >> > 'memory' annotation due to the way the memory map is mangled before
> >> >> >> > being supplied to the kexec kernel.
> >> >> >> >
> >> >> >> > Would it be possible to classify all memory that we want to hide from
> >> >> >> > the kexec kernel as NOMAP instead? That way, it will not be mapped
> >> >> >> > implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> >> >> >> > so this seems to be the most appropriate way to deal with the host
> >> >> >> > kernel's memory contents.
> >> >> >>
> >> >> >> Hmm. wouldn't appending the acpi reclaim regions to
> >> >> >> 'linux,usable-memory-range' in the dtb being passed to the crashkernel
> >> >> >> be better? Because its indirectly achieving a similar objective
> >> >> >> (although may be a subset of all System RAM regions on the primary
> >> >> >> kernel's memory).
> >> >> >>
> >> >> >> I am not aware of the background about the current kexec-tools
> >> >> >> implementation where we add only the crashkernel range to the dtb
> >> >> >> being passed to the crashkernel.
> >> >> >>
> >> >> >> Probably Akashi can answer better, as to how we arrived at this design
> >> >> >> approach and why we didn't want to expose all System RAM regions (i.e.
> >> >> >> ! NOMPAP regions) to the crashkernel.
> >> >> >>
> >> >> >> I am suspecting that some issues were seen/meet when the System RAM (!
> >> >> >> NOMAP regions) were exposed to the crashkernel, and that's why we
> >> >> >> finalized on this design approach, but this is something which is just
> >> >> >> my guess.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Bhupesh
> >> >> >>
> >> >> >> >>> >
> >> >> >> >>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> >> >> >>> > via a kernel command line parameter, "memmap=".
> >> >> >> >>>
> >> >> >> >>> memmap= is only used in old kexec-tools, now we are passing them via
> >> >> >> >>> e820 table.
> >> >> >> >>
> >> >> >> >> Thanks. I remember that you have explained it before.
> >> >> >> >>
> >> >> >> >> -Takahiro AKASHI
> >> >> >> >>
> >> >> >> >>> [snip]
> >> >> >> >>>
> >> >> >> >>> Thanks
> >> >> >> >>> Dave
> >> >> >
> >> >> > ===8<==
> >> >> > From 74e2451fea83d546feae76160ba7de426913fe03 Mon Sep 17 00:00:00 2001
> >> >> > From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> >> >> > Date: Thu, 21 Dec 2017 19:14:23 +0900
> >> >> > Subject: [PATCH] arm64: kdump: mark unusable memory as NOMAP
> >> >> >
> >> >> > ---
> >> >> > arch/arm64/mm/init.c | 10 ++++++++--
> >> >> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >> >> >
> >> >> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> >> >> > index 00e7b900ca41..8175db94257b 100644
> >> >> > --- a/arch/arm64/mm/init.c
> >> >> > +++ b/arch/arm64/mm/init.c
> >> >> > @@ -352,11 +352,17 @@ static void __init fdt_enforce_memory_region(void)
> >> >> > struct memblock_region reg = {
> >> >> > .size = 0,
> >> >> > };
> >> >> > + u64 idx;
> >> >> > + phys_addr_t start, end;
> >> >> >
> >> >> > of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >> >
> >> >> > - if (reg.size)
> >> >> > - memblock_cap_memory_range(reg.base, reg.size);
> >> >> > + if (reg.size) {
> >> >> > + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE,
> >> >> > + &start, &end, NULL)
> >> >> > + memblock_mark_nomap(start, end - start);
> >> >> > + memblock_clear_nomap(reg.base, reg.size);
> >> >> > + }
> >> >> > }
> >> >> >
> >> >> > void __init arm64_memblock_init(void)
> >> >> > --
> >> >> > 2.15.1
> >> >> >
> >> >>
> >> >> Thanks for the patch. After applying this on top of
> >> >> 4.15.0-rc4-next-20171220, there seems to be a improvement and the
> >> >> crashkernel boot no longer hangs while trying to access the acpi
> >> >> tables.
> >> >>
> >> >> However I notice a minor issue. Please see the log below for
> >> >> reference, the following message keeps spamming the console but I see
> >> >> the crashkernel boot proceed further.:
> >> >>
> >> >> [ 0.000000] ACPI: NUMA: SRAT: PXM 3 -> MPIDR 0x70303 -> Node 3
> >> >> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x3fffffff]
> >> >> [ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2000000000-0x2fffffffff]
> >> >> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x1000000000-0x1fffffffff]
> >> >> [ 0.000000] ACPI: SRAT: Node 3 PXM 3 [mem 0xa000000000-0xafffffffff]
> >> >> [ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x9000000000-0x9fffffffff]
> >> >> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffe200-0x1ffbffffff]
> >> >> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffc400-0x1ffbffe1ff]
> >> >> [ 0.000000] NUMA: NODE_DATA(1) on node 0
> >> >> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffa600-0x1ffbffc3ff]
> >> >> [ 0.000000] NUMA: NODE_DATA(2) on node 0
> >> >> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbff8800-0x1ffbffa5ff]
> >> >> [ 0.000000] NUMA: NODE_DATA(3) on node 0
> >> >> [ 0.000000] [ffff7fe008000000-ffff7fe00800ffff] potential offnode
> >> >> page_structs
> >> >> [ 0.000000] [ffff7fe008010000-ffff7fe00801ffff] potential offnode
> >> >> page_structs
> >> >> [ 0.000000] [ffff7fe008020000-ffff7fe00802ffff] potential offnode
> >> >> page_structs
> >> >> [ 0.000000] [ffff7fe008030000-ffff7fe00803ffff] potential offnode
> >> >> page_structs
> >> >> [ 0.000000] [ffff7fe008040000-ffff7fe00804ffff] potential offnode
> >> >> page_structs
> >> >> [ 0.000000] [ffff7fe008050000-ffff7fe00805ffff] potential offnode
> >> >> page_structs
> >> >>
> >> >> [snip..]
> >> >> [ 0.000000] [ffff7fe0081f0000-ffff7fe0081fffff] potential offnode
> >> >> page_structs
> >> >
> >> > These messages shows that some "struct page" data are allocated on remote
> >> > (numa) nodes.
> >> > Since on your crash dump kernel, all the usable system memory (starting
> >> > 0x0e800000) belongs to Node#0, we can't avoid such non-local allocations.
> >> >
> >> > In my best guess, you can ingore them except for some performance penality.
> >> > This may be one side-effect.
> >> >
> >> > So does your crash dump kernel now boot successfully?
> >> >
> >>
> >> Indeed. The crash dump kernel now boots successfully and the crash
> >> dump core can be saved properly as well (I tried saving it to local
> >> disk).
> >
> > Thank you for the confirmation.
> > (I'd like to suggest you to examine the core dump with crash utility.)
> >
> >> However, the 'potential offnode page_structs' WARN messages hog the
> >> console and delay crashkernel boot for a significant duration, which
> >> can be irritating.
> >>
> >> Can we also consider ratelimiting this WARNING message [which seems to
> >> come from vmemmap_verify()] if invoked in the context of crash kernel,
> >> in addition to making the above change suggested by you.
> >
> > Well, we may be able to change pr_warn() to pr_warn_once() here, but
> > I hope that adding "numa=off" to kernel command line should also work.
>
> Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
> my initial thought process as well, but I am not sure if this will
> cause any regressions on aarch64 systems which use crashdump feature.
It should be fine since we use numa=off by default for all other arches
ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
mm component memory usage.
>
> I think the 2nd solution, i.e limiting the warn message print
> frequency might be a better option. Can you please add the following
> patch (may be as a separate one) and send it along the patch which
> marks all areas other than the crashkernel region being passed to the
> crashkernel as NOMAP, so that we can get this issue fixed in upstream
> aarch64 kernel:
>
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index 17acf01791fa..4c13fe3c644d 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -169,7 +169,7 @@ void __meminit vmemmap_verify(pte_t *pte, int node,
> int actual_node = early_pfn_to_nid(pfn);
>
> if (node_distance(actual_node, node) > LOCAL_DISTANCE)
> - pr_warn("[%lx-%lx] potential offnode page_structs\n",
> + pr_warn_once("[%lx-%lx] potential offnode page_structs\n",
> start, end - 1);
> }
>
> I have tested this solution on huawei taishan board and can boot
> crashkernel successfully and also save the crash core properly
> (without the console warn message flooding which used to hold up the
> crashkernel boot).
>
> Thanks,
> Bhupesh
Thanks
Dave
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Dave Young @ 2017-12-26 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226013217.GA2119@dhcp-128-65.nay.redhat.com>
[snip]
> > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
> > > I hope that adding "numa=off" to kernel command line should also work.
> >
> > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
> > my initial thought process as well, but I am not sure if this will
> > cause any regressions on aarch64 systems which use crashdump feature.
>
> It should be fine since we use numa=off by default for all other arches
> ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
> mm component memory usage.
>
Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
^ permalink raw reply
* [PATCH -next] media: atmel-isc: Make local symbol fmt_configs_list static
From: Yang, Wenyou @ 2017-12-26 1:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513994224-86350-1-git-send-email-weiyongjun1@huawei.com>
On 2017/12/23 9:57, Wei Yongjun wrote:
> Fixes the following sparse warning:
>
> drivers/media/platform/atmel/atmel-isc.c:338:19: warning:
> symbol 'fmt_configs_list' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
> drivers/media/platform/atmel/atmel-isc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index 0c26356..2dd72fc 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -335,7 +335,7 @@ struct isc_device {
> },
> };
>
> -struct fmt_config fmt_configs_list[] = {
> +static struct fmt_config fmt_configs_list[] = {
> {
> .fourcc = V4L2_PIX_FMT_SBGGR8,
> .pfe_cfg0_bps = ISC_PFE_CFG0_BPS_EIGHT,
>
^ permalink raw reply
* [PATCH v4 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: Honghui Zhang @ 2017-12-26 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514197661.25015.9.camel@mtkswgap22>
On Mon, 2017-12-25 at 18:27 +0800, Ryder Lee wrote:
> On Fri, 2017-12-22 at 13:39 +0800, honghui.zhang at mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > The hardware default value of IDs and class type is not correct,
> > fix that by setup the correct values before start up.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
> > include/linux/pci_ids.h | 3 +++
> > 2 files changed, 15 insertions(+)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index fc29a9a..0ef33e4 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -74,6 +74,10 @@
> >
> > /* PCIe V2 per-port registers */
> > #define PCIE_MSI_VECTOR 0x0c0
> > +
> > +#define PCIE_CONF_ID 0x100
> > +#define PCIE_CONF_CLASS 0x104
> > +
> > #define PCIE_INT_MASK 0x420
> > #define INTX_MASK GENMASK(19, 16)
> > #define INTX_SHIFT 16
> > @@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
> > val |= PCIE_CSR_LTSSM_EN(port->slot) |
> > PCIE_CSR_ASPM_L1_EN(port->slot);
> > writel(val, pcie->base + PCIE_SYS_CFG_V2);
> > +
> > + /* Set up vendor ID and device ID for MT7622*/
> > + val = PCI_VENDOR_ID_MEDIATEK | (PCI_DEVICE_ID_MT7622 << 16);
> > + writel(val, port->base + PCIE_CONF_ID);
>
> IMHO, this is a general function so you can ignore "device ID for
> MT7622" here, but just make sure class code/vendor ID correct.
Hmm, this condition is only for MT7622 for now.
Well, host driver and framework does not cares about the device ID for
host bridge. I guess I can bypass the setting of device ID.
thanks.
>
> > + /* Set up class code for MT7622 */
> > + val = PCI_CLASS_BRIDGE_PCI << 16;
> > + writel(val, port->base + PCIE_CONF_CLASS);
> > }
> >
> > /* Assert all reset signals */
> > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> > index ab20dc5..000c5df 100644
>
^ permalink raw reply
* [RFC PATCH v12 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Jeffy Chen @ 2017-12-26 2:08 UTC (permalink / raw)
To: linux-arm-kernel
Currently we are handling wake irq in mrvl wifi driver. Move it into
pci core.
Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
Changes in v12:
Enable the wake irq in noirq stage to avoid possible irq storm.
Changes in v11:
Only add irq definitions for PCI devices and rewrite the commit message.
Address Brian's comments.
Only support 1-per-device PCIe WAKE# pin as suggested.
Move to pcie port as Brian suggested.
Changes in v10:
Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
Changes in v9:
Add section for PCI devices and rewrite the commit message.
Fix check error in .cleanup().
Move dedicated wakeirq setup to setup() callback and use
device_set_wakeup_enable() to enable/disable.
Rewrite the commit message.
Changes in v8:
Add optional "pci", and rewrite commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
Rewrite the commit message.
Changes in v7:
Move PCIE_WAKE handling into pci core.
Changes in v6:
Fix device_init_wake error handling, and add some comments.
Changes in v5:
Move to pci.txt
Rebase.
Use "wakeup" instead of "wake"
Changes in v3:
Fix error handling.
Changes in v2:
Use dev_pm_set_dedicated_wake_irq.
Jeffy Chen (5):
dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
of/irq: Adjust of_pci_irq parsing for multiple interrupts
mwifiex: Disable wakeup irq handling for pcie
PCI / PM: Add support for the PCIe WAKE# signal for OF
arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
Documentation/devicetree/bindings/pci/pci.txt | 10 ++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 11 ++--
drivers/net/wireless/marvell/mwifiex/main.c | 4 ++
drivers/of/of_pci_irq.c | 74 ++++++++++++++++++++++++--
drivers/pci/Makefile | 1 +
drivers/pci/pci-driver.c | 10 ++++
drivers/pci/pci-of.c | 75 +++++++++++++++++++++++++++
include/linux/of_pci.h | 9 ++++
8 files changed, 186 insertions(+), 8 deletions(-)
create mode 100644 drivers/pci/pci-of.c
--
2.11.0
^ permalink raw reply
* [RFC PATCH v12 5/5] arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
From: Jeffy Chen @ 2017-12-26 2:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226020806.32710-1-jeffy.chen@rock-chips.com>
Currently we are handling PCIe WAKE# irq in mrvl wifi driver.
Move it to rockchip pcie port since we are going to handle it in the
pci core.
Also avoid this irq been considered as the PCI interrupt pin in the
of_irq_parse_pci().
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
Changes in v12: None
Changes in v11:
Move to pcie port as Brian suggested.
Changes in v10: None
Changes in v9:
Rewrite the commit message.
Changes in v8:
Rewrite the commit message.
Changes in v7: None
Changes in v6: None
Changes in v5:
Use "wakeup" instead of "wake"
Changes in v3: None
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 03f195025390..be41d363efd8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -719,15 +719,16 @@ ap_i2c_audio: &i2c8 {
#size-cells = <2>;
ranges;
+ interrupts-extended = <&pcie0 1>, <&gpio0 8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "pci", "wakeup";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_host_wake_l>;
+ wakeup-source;
+
mvl_wifi: wifi at 0,0 {
compatible = "pci1b4b,2b42";
reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
0x83010000 0x0 0x00100000 0x0 0x00100000>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_host_wake_l>;
- wakeup-source;
};
};
};
--
2.11.0
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-26 2:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226013517.GA2186@dhcp-128-65.nay.redhat.com>
On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
> [snip]
> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
> > > > I hope that adding "numa=off" to kernel command line should also work.
> > >
> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
> > > my initial thought process as well, but I am not sure if this will
> > > cause any regressions on aarch64 systems which use crashdump feature.
> >
> > It should be fine since we use numa=off by default for all other arches
> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
> > mm component memory usage.
> >
>
> Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
Thank you for the clarification.
(It might be better to make numa off automatically if maxcpus == 0 (and 1?).)
-Takahiro AKASHI
^ permalink raw reply
* [RFC PATCH v12 0/5] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Jeffy Chen @ 2017-12-26 2:36 UTC (permalink / raw)
To: linux-arm-kernel
Currently we are handling wake irq in mrvl wifi driver. Move it into
pci core.
Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
Changes in v13:
Fix compiler error reported by kbuild test robot <fengguang.wu@intel.com>
Changes in v12:
Only add irq definitions for PCI devices and rewrite the commit message.
Enable the wake irq in noirq stage to avoid possible irq storm.
Changes in v11:
Address Brian's comments.
Only support 1-per-device PCIe WAKE# pin as suggested.
Move to pcie port as Brian suggested.
Changes in v10:
Use device_set_wakeup_capable() instead of device_set_wakeup_enable(),
since dedicated wakeirq will be lost in device_set_wakeup_enable(false).
Changes in v9:
Add section for PCI devices and rewrite the commit message.
Fix check error in .cleanup().
Move dedicated wakeirq setup to setup() callback and use
device_set_wakeup_enable() to enable/disable.
Rewrite the commit message.
Changes in v8:
Add optional "pci", and rewrite commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
Rewrite the commit message.
Changes in v7:
Move PCIE_WAKE handling into pci core.
Changes in v6:
Fix device_init_wake error handling, and add some comments.
Changes in v5:
Move to pci.txt
Rebase.
Use "wakeup" instead of "wake"
Changes in v3:
Fix error handling.
Changes in v2:
Use dev_pm_set_dedicated_wake_irq.
Jeffy Chen (5):
dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
of/irq: Adjust of_pci_irq parsing for multiple interrupts
mwifiex: Disable wakeup irq handling for pcie
PCI / PM: Add support for the PCIe WAKE# signal for OF
arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
Documentation/devicetree/bindings/pci/pci.txt | 10 ++++
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 11 ++--
drivers/net/wireless/marvell/mwifiex/main.c | 4 ++
drivers/of/of_pci_irq.c | 71 +++++++++++++++++++++++--
drivers/pci/Makefile | 1 +
drivers/pci/pci-driver.c | 10 ++++
drivers/pci/pci-of.c | 75 +++++++++++++++++++++++++++
include/linux/of_pci.h | 9 ++++
8 files changed, 183 insertions(+), 8 deletions(-)
create mode 100644 drivers/pci/pci-of.c
--
2.11.0
^ permalink raw reply
* [RFC PATCH v12 5/5] arm64: dts: rockchip: Move PCIe WAKE# irq to pcie port for Gru
From: Jeffy Chen @ 2017-12-26 2:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226023646.17722-1-jeffy.chen@rock-chips.com>
Currently we are handling PCIe WAKE# irq in mrvl wifi driver.
Move it to rockchip pcie port since we are going to handle it in the
pci core.
Also avoid this irq been considered as the PCI interrupt pin in the
of_irq_parse_pci().
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
Changes in v13: None
Changes in v12: None
Changes in v11:
Move to pcie port as Brian suggested.
Changes in v10: None
Changes in v9:
Rewrite the commit message.
Changes in v8:
Rewrite the commit message.
Changes in v7: None
Changes in v6: None
Changes in v5:
Use "wakeup" instead of "wake"
Changes in v3: None
Changes in v2: None
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
index 03f195025390..be41d363efd8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi
@@ -719,15 +719,16 @@ ap_i2c_audio: &i2c8 {
#size-cells = <2>;
ranges;
+ interrupts-extended = <&pcie0 1>, <&gpio0 8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "pci", "wakeup";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wlan_host_wake_l>;
+ wakeup-source;
+
mvl_wifi: wifi at 0,0 {
compatible = "pci1b4b,2b42";
reg = <0x83010000 0x0 0x00000000 0x0 0x00100000
0x83010000 0x0 0x00100000 0x0 0x00100000>;
- interrupt-parent = <&gpio0>;
- interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&wlan_host_wake_l>;
- wakeup-source;
};
};
};
--
2.11.0
^ permalink raw reply related
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh Sharma @ 2017-12-26 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171226022807.GB8877@linaro.org>
On Tue, Dec 26, 2017 at 7:58 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Tue, Dec 26, 2017 at 09:35:17AM +0800, Dave Young wrote:
>> [snip]
>> > > > Well, we may be able to change pr_warn() to pr_warn_once() here, but
>> > > > I hope that adding "numa=off" to kernel command line should also work.
>> > >
>> > > Hmm, adding "numa=off" to crashkernel bootargs works, and TBH it was
>> > > my initial thought process as well, but I am not sure if this will
>> > > cause any regressions on aarch64 systems which use crashdump feature.
>> >
>> > It should be fine since we use numa=off by default for all other arches
>> > ie. x86, ppc64 and s390. Actually disabling numa in kdump kernel can save
>> > mm component memory usage.
>> >
>>
>> Forgot to say I means in RHEL and Fedora we use numa=off for kdump..
>
> Thank you for the clarification.
> (It might be better to make numa off automatically if maxcpus == 0 (and 1?).)
>
Not sure if we can leave this to the distribution-specific kdump
scripts (as the crashkernel boot can be held up for sufficient time
and may appear stuck). The distribution scripts may be different (for
e.g. ubuntu and RHEL/fedora) across distributions and may have
different bootarg options.
So how about considering a kernel fix only which doesn't require
relying on changing the distribution-specific kdump scripts, as we
should avoid introducing a regression while trying to fix a regression
:)
Just my 2 cents.
Thanks,
Bhupesh
^ permalink raw reply
* [PATCH net-next v8 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
From: Florian Fainelli @ 2017-12-26 3:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514164238-28901-2-git-send-email-hayashi.kunihiko@socionext.com>
On December 24, 2017 5:10:37 PM PST, Kunihiko Hayashi <hayashi.kunihiko@socionext.com> 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>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH] arm: imx: suspend/resume: use outer_disable/resume
From: Shawn Guo @ 2017-12-26 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171210120718.15197-1-peng.fan@nxp.com>
On Sun, Dec 10, 2017 at 08:07:18PM +0800, Peng Fan wrote:
> Use outer_disable/resume for suspend/resume.
> With the two APIs used, code could be simplified and easy to extend
> to introduce l2c_write_sec for i.MX platforms when moving Linux Kernel
> runs in non-secure world.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Dong Aisheng <aisheng.dong@nxp.com>
> ---
> arch/arm/mach-imx/pm-imx6.c | 2 ++
> arch/arm/mach-imx/suspend-imx6.S | 24 ------------------------
I'm fine with the patch in general. But this piece of code is running
on a few i.MX6 platforms, and I'm wondering on which SoCs you have
verified the change work fine.
Shawn
^ permalink raw reply
* [PATCH v2] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform
From: Shawn Guo @ 2017-12-26 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211115126.14553-1-sz.lin@moxa.com>
On Mon, Dec 11, 2017 at 07:51:25PM +0800, SZ Lin wrote:
> Add support for Moxa UC-8410A open platform
>
> The UC-8410A computing platform is designed
> for embedded communication-centric industrial applications
>
> The features of UC-8410A are:
> * QSPI flash
> * SD slot
> * 3x LAN
> * 8x RS-232/422/485 ports, software-selectable
> * Mini PCIe form factor with PCIe/USB signal
> * 2x USB host
> * TPM
> * Watchdog
> * RTC
> * User LEDs
> * Beeper
> * Push button
>
> Signed-off-by: Jimmy Chen <jimmy.chen@moxa.com>
> Signed-off-by: Harry YJ Jhou <harryyj.jhou@moxa.com>
> Signed-off-by: SZ Lin <sz.lin@moxa.com>
>
> --
> Changes from v1:
> - Add newline between nodes
> - Add push button node
> - Insert newline between property list and child node
> - Include file of "include/dt-bindings/gpio/gpio.h"
> - Include file of "include/dt-bindings/input/input.h"
> - Use polartiy defines for gpios to make it more readable
> - Put 'status' at the end of property list
> - Change GPIO pin number in cel_pwr and cel_reset
> - Sort the labeled node alphabetically
> - Drop container node of regulator and put fixed regulator directly
> under root
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 ++++++++++++++++++++++++++++
> 2 files changed, 242 insertions(+)
> create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..62ce9b27ad30 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
> imx7s-colibri-eval-v3.dtb \
> imx7s-warp.dtb
> dtb-$(CONFIG_SOC_LS1021A) += \
> + ls1021a-moxa-uc-8410a.dtb \
> ls1021a-qds.dtb \
> ls1021a-twr.dtb
> dtb-$(CONFIG_SOC_VF610) += \
> diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> new file mode 100644
> index 000000000000..bc73b5187990
> --- /dev/null
> +++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
> + *
> + * Author: Harry YJ Jhou (???) <harryyj.jhou@moxa.com>
> + * Jimmy Chen (???) <jimmy.chen@moxa.com>
> + * SZ Lin (???) <sz.lin@moxa.com>
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include "ls1021a.dtsi"
> +
> +/ {
> + model = "Moxa UC-8410A";
> +
> + aliases {
> + enet0_rgmii_phy = &rgmii_phy0;
> + enet1_rgmii_phy = &rgmii_phy1;
> + enet2_rgmii_phy = &rgmii_phy2;
> + };
> +
> + sys_mclk: clock-mclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24576000>;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + cel_pwr {
We generally use hyphen rather than underscore in node name.
> + label = "UC8410A:CEL-PWR";
> + gpios = <&gpio3 27 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + cel_reset {
> + label = "UC8410A:CEL-RESET";
> + gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + str_led {
> + label = "UC8410A:RED:PROG";
> + gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + };
> +
> + sw_ready {
> + label = "UC8410A:GREEN:SWRDY";
> + gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + beeper {
> + label = "UC8410A:BEEP";
> + gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led0 {
> + label = "UC8410A:GREEN:PROG2";
> + gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led1 {
> + label = "UC8410A:GREEN:PROG1";
> + gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led2 {
> + label = "UC8410A:GREEN:PROG0";
> + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + wifi_signal0 {
> + label = "UC8410A:GREEN:CEL2";
> + gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + wifi_signal1 {
> + label = "UC8410A:GREEN:CEL1";
> + gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + wifi_signal2 {
> + label = "UC8410A:GREEN:CEL0";
> + gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + cpu_diag_red {
> + label = "UC8410A:RED:DIA";
> + gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + cpu_diag_green {
> + label = "UC8410A:GREEN:DIA";
> + gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + cpu_diag_yellow {
> + label = "UC8410A:YELLOW:DIA";
> + gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pushbtn-key {
> + label = "push button key";
> + gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
> + linux,code = <BTN_MISC>;
> + default-state = "on";
> + };
> + };
> +};
> +
> +&enet0 {
> + phy-handle = <&rgmii_phy0>;
> + phy-connection-type = "rgmii-id";
> + status = "okay";
> +};
> +
> +&enet1 {
> + phy-handle = <&rgmii_phy1>;
> + phy-connection-type = "rgmii-id";
> + status = "okay";
> +};
> +
> +&enet2 {
> + phy-handle = <&rgmii_phy2>;
> + phy-connection-type = "rgmii-id";
> + status = "okay";
> +};
> +
> +&i2c0 {
> + clock-frequency = <100000>;
> + status = "okay";
> +
> + rtc {
Nodes with 'reg' property should have a match unit-address after node name.
> + compatible = "dallas,ds1374";
> + reg = <0x68>;
> + };
> +
> + tpm {
Sort nodes with unit-address in order of the address.
> + compatible = "infineon,slb9635tt";
> + reg = <0x20>;
> + };
> +};
> +
> +&lpuart0 {
> + status = "okay";
> +};
> +
> +&mdio0 {
> + rgmii_phy0: ethernet-phy at 0 {
> + compatible = "marvell,88e1118";
> + reg = <0x0>;
> + marvell,reg-init =
> + <3 0x11 0 0x4415>, /* Reg 3,17 */
> + <3 0x10 0 0x77>; /* Reg 3,16 */
> + };
> +
> + rgmii_phy1: ethernet-phy at 1 {
> + compatible = "marvell,88e1118";
> + reg = <0x1>;
> + marvell,reg-init =
> + <3 0x11 0 0x4415>, /* Reg 3,17 */
> + <3 0x10 0 0x77>; /* Reg 3,16 */
> + };
> +
> + rgmii_phy2: ethernet-phy at 2 {
> + compatible = "marvell,88e1118";
> + reg = <0x2>;
> + marvell,reg-init =
> + <3 0x11 0 0x4415>, /* Reg 3,17 */
> + <3 0x10 0 0x77>; /* Reg 3,16 */
> + };
> +};
> +
> +&qspi {
> + bus-num = <0>;
> + fsl,spi-num-chipselects = <2>;
> + fsl,spi-flash-chipselects = <0>;
> + fsl,qspi-has-second-chip;
> + status = "okay";
> +
> + flash: flash at 0 {
> + compatible = "spansion,s25fl064l", "spansion,s25fl164k";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + spi-max-frequency = <20000000>;
> + reg = <0>;
> +
> + partitions at 0 {
> + label = "U-Boot";
> + reg = <0x0 0x180000>;
> + };
> +
> + partitions at 1 {
The unit-address doesn't match 'reg' property.
Shawn
> + label = "U-Boot Env";
> + reg = <0x180000 0x680000>;
> + };
> + };
> +};
> +
> +&sata {
> + status = "okay";
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> --
> 2.15.1
>
^ permalink raw reply
* [PATCH 00/20] Add Hummingboard 2 support
From: Shawn Guo @ 2017-12-26 4:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211165631.GW10595@n2100.armlinux.org.uk>
On Mon, Dec 11, 2017 at 04:56:31PM +0000, Russell King - ARM Linux wrote:
> Hi,
>
> This series adds the long awaited Hummingboard 2 support to the
> mainline kernel.
>
> While I could squash the patch set down, I've not done this because
> this is the result of several different people over the course of
> the last couple of years, and I believe it's not right to lose the
> detail of their contributions.
>
> This builds upon the previous set of changes for the Hummingboard,
> which re-organised the way we deal with the uSOM and baseboards.
>
> arch/arm/boot/dts/Makefile | 6 +
> .../boot/dts/imx6dl-hummingboard2-emmc-som-v15.dts | 55 +++
> arch/arm/boot/dts/imx6dl-hummingboard2-som-v15.dts | 54 +++
> arch/arm/boot/dts/imx6dl-hummingboard2.dts | 53 ++
> .../boot/dts/imx6q-hummingboard2-emmc-som-v15.dts | 63 +++
> arch/arm/boot/dts/imx6q-hummingboard2-som-v15.dts | 62 +++
> arch/arm/boot/dts/imx6q-hummingboard2.dts | 61 +++
> arch/arm/boot/dts/imx6qdl-hummingboard2-emmc.dtsi | 72 +++
> arch/arm/boot/dts/imx6qdl-hummingboard2.dtsi | 540 +++++++++++++++++++++
> 9 files changed, 966 insertions(+)
Applied all, thanks.
^ permalink raw reply
* [PATCH] ARM: dts: imx51: add CodaHx4 VPU
From: Shawn Guo @ 2017-12-26 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213142406.5088-1-p.zabel@pengutronix.de>
On Wed, Dec 13, 2017 at 03:24:06PM +0100, Philipp Zabel wrote:
> Add the CodaHx4 VPU to the i.MX51 device tree.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> This patch should only be applied once the patch to fix VPU register access on
> i.MX51 [1] is merged. The coda driver with patches [2] applied will start
> accessing VPU registers on i.MX51, which hangs the system without [1].
Ping me when it can be safely applied on IMX tree.
Shawn
^ permalink raw reply
* [PATCH 05/25] arm: imx: dts: Remove leading 0x and 0s from bindings notation
From: Shawn Guo @ 2017-12-26 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215111620.20379-5-malat@debian.org>
On Fri, Dec 15, 2017 at 12:15:55PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/imx6q-display5.dtsi | 2 +-
> arch/arm/boot/dts/imx7d.dtsi | 2 +-
> arch/arm/boot/dts/imx7s.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q-display5.dtsi b/arch/arm/boot/dts/imx6q-display5.dtsi
> index 4084de43d4d9..09085fde3341 100644
> --- a/arch/arm/boot/dts/imx6q-display5.dtsi
> +++ b/arch/arm/boot/dts/imx6q-display5.dtsi
> @@ -255,7 +255,7 @@
> pinctrl-0 = <&pinctrl_i2c1>;
> status = "okay";
>
> - codec: tfa9879 at 6C {
> + codec: tfa9879 at 6c {
> #sound-dai-cells = <0>;
> compatible = "nxp,tfa9879";
> reg = <0x6C>;
> diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
> index 4d308d17f040..369d5a166b3e 100644
> --- a/arch/arm/boot/dts/imx7d.dtsi
> +++ b/arch/arm/boot/dts/imx7d.dtsi
> @@ -129,7 +129,7 @@
> status = "disabled";
> };
>
> - pcie: pcie at 0x33800000 {
> + pcie: pcie at 33800000 {
> compatible = "fsl,imx7d-pcie", "snps,dw-pcie";
> reg = <0x33800000 0x4000>,
> <0x4ff00000 0x80000>;
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 82ad26e766eb..a00ba897e58d 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -583,7 +583,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
>
> - pgc_pcie_phy: pgc-power-domain at IMX7_POWER_DOMAIN_PCIE_PHY {
> + pgc_pcie_phy: pgc-power-domain at imx7_power_domain_pcie_phy {
I think this is broken, as IMX7_POWER_DOMAIN_PCIE_PHY is a define here.
Shawn
> #power-domain-cells = <0>;
> reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
> power-supply = <®_1p0d>;
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v3] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform
From: SZ Lin @ 2017-12-26 4:54 UTC (permalink / raw)
To: linux-arm-kernel
Add support for Moxa UC-8410A open platform
The UC-8410A computing platform is designed
for embedded communication-centric industrial applications
The features of UC-8410A are:
* QSPI flash
* SD slot
* 3x LAN
* 8x RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with PCIe/USB signal
* 2x USB host
* TPM
* Watchdog
* RTC
* User LEDs
* Beeper
* Push button
Signed-off-by: Jimmy Chen <jimmy.chen@moxa.com>
Signed-off-by: Harry YJ Jhou <harryyj.jhou@moxa.com>
Signed-off-by: SZ Lin <sz.lin@moxa.com>
---
Changes from v2:
- Replace underscore with hyphen in node name
- Add unit address after nodes with 'reg' property
- Sort nodes with unit-address in order of the address
- Fix up unit-address in partitions node
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 ++++++++++++++++++++++++++++
2 files changed, 242 insertions(+)
create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..62ce9b27ad30 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
dtb-$(CONFIG_SOC_LS1021A) += \
+ ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
dtb-$(CONFIG_SOC_VF610) += \
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
new file mode 100644
index 000000000000..d01f64b252b1
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
+ *
+ * Author: Harry YJ Jhou (???) <harryyj.jhou@moxa.com>
+ * Jimmy Chen (???) <jimmy.chen@moxa.com>
+ * SZ Lin (???) <sz.lin@moxa.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "ls1021a.dtsi"
+
+/ {
+ model = "Moxa UC-8410A";
+
+ aliases {
+ enet0_rgmii_phy = &rgmii_phy0;
+ enet1_rgmii_phy = &rgmii_phy1;
+ enet2_rgmii_phy = &rgmii_phy2;
+ };
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ cel-pwr {
+ label = "UC8410A:CEL-PWR";
+ gpios = <&gpio3 27 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ cel-reset {
+ label = "UC8410A:CEL-RESET";
+ gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ str-led {
+ label = "UC8410A:RED:PROG";
+ gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "mmc0";
+ };
+
+ sw-ready {
+ label = "UC8410A:GREEN:SWRDY";
+ gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ beeper {
+ label = "UC8410A:BEEP";
+ gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog-led0 {
+ label = "UC8410A:GREEN:PROG2";
+ gpios = <&gpio3 14 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog-led1 {
+ label = "UC8410A:GREEN:PROG1";
+ gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ prog-led2 {
+ label = "UC8410A:GREEN:PROG0";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi-signal0 {
+ label = "UC8410A:GREEN:CEL2";
+ gpios = <&gpio3 17 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi-signal1 {
+ label = "UC8410A:GREEN:CEL1";
+ gpios = <&gpio3 18 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ wifi-signal2 {
+ label = "UC8410A:GREEN:CEL0";
+ gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu-diag-red {
+ label = "UC8410A:RED:DIA";
+ gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu-diag-green {
+ label = "UC8410A:GREEN:DIA";
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+
+ cpu-diag-yellow {
+ label = "UC8410A:YELLOW:DIA";
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pushbtn-key {
+ label = "push button key";
+ gpios = <&gpio1 21 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ default-state = "on";
+ };
+ };
+};
+
+&enet0 {
+ phy-handle = <&rgmii_phy0>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet1 {
+ phy-handle = <&rgmii_phy1>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&enet2 {
+ phy-handle = <&rgmii_phy2>;
+ phy-connection-type = "rgmii-id";
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ tpm at 20 {
+ compatible = "infineon,slb9635tt";
+ reg = <0x20>;
+ };
+
+ rtc at 68 {
+ compatible = "dallas,ds1374";
+ reg = <0x68>;
+ };
+};
+
+&lpuart0 {
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy at 0 {
+ compatible = "marvell,88e1118";
+ reg = <0x0>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy1: ethernet-phy at 1 {
+ compatible = "marvell,88e1118";
+ reg = <0x1>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+
+ rgmii_phy2: ethernet-phy at 2 {
+ compatible = "marvell,88e1118";
+ reg = <0x2>;
+ marvell,reg-init =
+ <3 0x11 0 0x4415>, /* Reg 3,17 */
+ <3 0x10 0 0x77>; /* Reg 3,16 */
+ };
+};
+
+&qspi {
+ bus-num = <0>;
+ fsl,spi-num-chipselects = <2>;
+ fsl,spi-flash-chipselects = <0>;
+ fsl,qspi-has-second-chip;
+ status = "okay";
+
+ flash: flash at 0 {
+ compatible = "spansion,s25fl064l", "spansion,s25fl164k";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+
+ partitions at 0 {
+ label = "U-Boot";
+ reg = <0x0 0x180000>;
+ };
+
+ partitions at 180000 {
+ label = "U-Boot Env";
+ reg = <0x180000 0x680000>;
+ };
+ };
+};
+
+&sata {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 06/11 v2] ARM: davinci: constify gpio_led
From: Arvind Yadav @ 2017-12-26 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <de0879ef47b96776e3f18a1889c41d976a677b21.1514267721.git.arvind.yadav.cs@gmail.com>
gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by <linux/leds.h>. So mark the non-const structs
as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
changes in v2:
The GPIO LED driver can be built as a module, it can
be loaded after the init sections have gone away.
So removed '__initconst'.
arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-davinci/board-neuros-osd2.c
index 0c02aaa..4da210a 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -128,7 +128,7 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
-static struct gpio_led ntosd2_leds[] = {
+static const struct gpio_led ntosd2_leds[] = {
{ .name = "led1_green", .gpio = GPIO(10), },
{ .name = "led1_red", .gpio = GPIO(11), },
{ .name = "led2_green", .gpio = GPIO(12), },
--
2.7.4
^ 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