* [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Jason Gunthorpe @ 2016-10-17 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476733214-19044-1-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>
> drivers/char/hw_random/meson-rng.c | 1 +
> drivers/char/tpm/Kconfig | 2 +-
Looks like this patch should not have tpm in it.
Jason
^ permalink raw reply
* [PATCH 5/5] MAINTAINERS: Add the staging vchiq driver as a bcm2835 responsibility.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-1-eric@anholt.net>
It's being merged to support firmware communication on the Raspberry
Pi, so we should probably send its patches to linux-rpi-kernel.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
Greg, I'd be pulling this one through broadcom trees.
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1cd38a7e0064..8ed85a51d9c1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2586,6 +2586,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
T: git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
S: Maintained
N: bcm2835
+F: drivers/staging/vc04_services
BROADCOM BCM47XX MIPS ARCHITECTURE
M: Hauke Mehrtens <hauke@hauke-m.de>
--
2.9.3
^ permalink raw reply related
* [PATCH 4/5] staging/vchi: Add a TODO file of things I know we need to deal with.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-1-eric@anholt.net>
I've left out the downstream HDMI audio driver from the "to be
imported" section, as we'll want to handle it natively in vc4. The
downstream kernel will likely continue to use that driver for a while
due to using the interim "vc4 firmware KMS" mode while vc4 gets its
featureset (such as HDMI audio!) completed.
I've also left out VC-CMA, which appears to be about having Linux
manage a CMA area that the firmware gets to make allocations out of.
I'm not clear on if this is useful (the firmware's need for memory
drops massively with vc4 present, and may drop even more depending on
how we resolve dmabuf handling for camera and video decode)
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/interface/vchi/TODO | 50 +++++++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 drivers/staging/vc04_services/interface/vchi/TODO
diff --git a/drivers/staging/vc04_services/interface/vchi/TODO b/drivers/staging/vc04_services/interface/vchi/TODO
new file mode 100644
index 000000000000..03aa65183b25
--- /dev/null
+++ b/drivers/staging/vc04_services/interface/vchi/TODO
@@ -0,0 +1,50 @@
+1) Port to aarch64
+
+This driver won't be very useful unless we also have it working on
+Raspberry Pi 3. This requires, at least:
+
+ - Figure out an alternative to the dmac_map_area() hack.
+
+ - Decide what to use instead of dsb().
+
+ - Do something about (int) cast of bulk->data in
+ vchiq_bulk_transfer().
+
+ bulk->data is a bus address going across to the firmware. We know
+ our bus addresses are <32bit.
+
+2) Write a DT binding doc and get the corresponding DT node merged to
+ bcm2835.
+
+This will let the driver probe when enabled.
+
+3) Import drivers using VCHI.
+
+VCHI is just a tool to let drivers talk to the firmware. Here are
+some of the ones we want:
+
+ - vc_mem (https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/char/broadcom/vc_mem.c)
+
+ This driver is what the vcdbg userspace program uses to set up its
+ requests to the firmware, which are transmitted across VCHIQ. vcdbg
+ is really useful for debugging firmware interactions.
+
+ - bcm2835-camera (https://github.com/raspberrypi/linux/tree/rpi-4.4.y/drivers/media/platform/bcm2835)
+
+ This driver will let us get images from the camera using the MMAL
+ protocol over VCHI.
+
+ - VCSM (https://github.com/raspberrypi/linux/tree/rpi-4.4.y/drivers/char/broadcom/vc_sm)
+
+ This driver is used for talking about regions of VC memory across
+ firmware protocols including VCHI. We'll want to extend this driver
+ to manage these buffers as dmabufs so that we can zero-copy import
+ camera images into vc4 for rendering/display.
+
+4) Garbage-collect unused code
+
+One of the reasons this driver wasn't upstreamed previously was that
+there's a lot code that got built that's probably unnecessary these
+days. Once we have the set of VCHI-using drivers we want in tree, we
+should be able to do a sweep of the code to see what's left that's
+unused.
--
2.9.3
^ permalink raw reply related
* [PATCH 3/5] staging/vchi: Fix some pointer math for 64-bit.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-1-eric@anholt.net>
These were throwing warnings on aarch64, and all are trivially
converted to longs.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 6 +++---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 5 +++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index c5255bc6c589..3c7165b34dab 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -121,7 +121,7 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
return -ENOMEM;
}
- WARN_ON(((int)slot_mem & (PAGE_SIZE - 1)) != 0);
+ WARN_ON(((unsigned long)slot_mem & (PAGE_SIZE - 1)) != 0);
vchiq_slot_zero = vchiq_init_slots(slot_mem, slot_mem_size);
if (!vchiq_slot_zero)
@@ -222,7 +222,7 @@ remote_event_signal(REMOTE_EVENT_T *event)
int
vchiq_copy_from_user(void *dst, const void *src, int size)
{
- if ((uint32_t)src < TASK_SIZE) {
+ if ((unsigned long)src < TASK_SIZE) {
return copy_from_user(dst, src, size);
} else {
memcpy(dst, src, size);
@@ -375,7 +375,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
int run, addridx, actual_pages;
unsigned long *need_release;
- offset = (unsigned int)buf & (PAGE_SIZE - 1);
+ offset = (unsigned long)buf & (PAGE_SIZE - 1);
num_pages = (count + offset + PAGE_SIZE - 1) / PAGE_SIZE;
*ppagelist = NULL;
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 93a6ac75791f..6862cbc0d7a9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1723,7 +1723,7 @@ parse_rx_slots(VCHIQ_STATE_T *state)
min(64, size));
}
- if (((unsigned int)header & VCHIQ_SLOT_MASK) + calc_stride(size)
+ if (((unsigned long)header & VCHIQ_SLOT_MASK) + calc_stride(size)
> VCHIQ_SLOT_SIZE) {
vchiq_log_error(vchiq_core_log_level,
"header %p (msgid %x) - size %x too big for "
@@ -2268,7 +2268,8 @@ get_conn_state_name(VCHIQ_CONNSTATE_T conn_state)
VCHIQ_SLOT_ZERO_T *
vchiq_init_slots(void *mem_base, int mem_size)
{
- int mem_align = (VCHIQ_SLOT_SIZE - (int)mem_base) & VCHIQ_SLOT_MASK;
+ int mem_align = (VCHIQ_SLOT_SIZE -
+ (unsigned long)mem_base) & VCHIQ_SLOT_MASK;
VCHIQ_SLOT_ZERO_T *slot_zero =
(VCHIQ_SLOT_ZERO_T *)((char *)mem_base + mem_align);
int num_slots = (mem_size - mem_align)/VCHIQ_SLOT_SIZE;
--
2.9.3
^ permalink raw reply related
* [PATCH 2/5] staging/vchi: Fix build warnings when formatting pointers on aarch64.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-1-eric@anholt.net>
The code was generally using "%x" to print and "(unsigned int)" to
cast the pointers, but we have %p for printing pointers in the same
format without any broken casts.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
.../interface/vchiq_arm/vchiq_2835_arm.c | 9 +-
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 32 ++--
.../vc04_services/interface/vchiq_arm/vchiq_core.c | 178 ++++++++++-----------
3 files changed, 109 insertions(+), 110 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
index 4cb5bff23728..c5255bc6c589 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -174,8 +174,8 @@ int vchiq_platform_init(struct platform_device *pdev, VCHIQ_STATE_T *state)
}
vchiq_log_info(vchiq_arm_log_level,
- "vchiq_init - done (slots %x, phys %pad)",
- (unsigned int)vchiq_slot_zero, &slot_phys);
+ "vchiq_init - done (slots %p, phys %pad)",
+ vchiq_slot_zero, &slot_phys);
vchiq_call_connected_callbacks();
@@ -389,8 +389,7 @@ create_pagelist(char __user *buf, size_t count, unsigned short type,
(num_pages * sizeof(pages[0])),
GFP_KERNEL);
- vchiq_log_trace(vchiq_arm_log_level,
- "create_pagelist - %x", (unsigned int)pagelist);
+ vchiq_log_trace(vchiq_arm_log_level, "create_pagelist - %p", pagelist);
if (!pagelist)
return -ENOMEM;
@@ -515,7 +514,7 @@ free_pagelist(PAGELIST_T *pagelist, int actual)
unsigned int num_pages, i;
vchiq_log_trace(vchiq_arm_log_level,
- "free_pagelist - %x, %d", (unsigned int)pagelist, actual);
+ "free_pagelist - %p, %d", pagelist, actual);
num_pages =
(pagelist->length + pagelist->offset + PAGE_SIZE - 1) /
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 47df1af2219d..68ee5216f5bc 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -418,8 +418,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
DEBUG_INITIALISE(g_state.local)
vchiq_log_trace(vchiq_arm_log_level,
- "vchiq_ioctl - instance %x, cmd %s, arg %lx",
- (unsigned int)instance,
+ "vchiq_ioctl - instance %p, cmd %s, arg %lx",
+ instance,
((_IOC_TYPE(cmd) == VCHIQ_IOC_MAGIC) &&
(_IOC_NR(cmd) <= VCHIQ_IOC_MAX)) ?
ioctl_names[_IOC_NR(cmd)] : "<invalid>", arg);
@@ -713,8 +713,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
break;
}
vchiq_log_info(vchiq_arm_log_level,
- "found bulk_waiter %x for pid %d",
- (unsigned int)waiter, current->pid);
+ "found bulk_waiter %p for pid %d",
+ waiter, current->pid);
args.userdata = &waiter->bulk_waiter;
}
status = vchiq_bulk_transfer
@@ -743,8 +743,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
list_add(&waiter->list, &instance->bulk_waiter_list);
mutex_unlock(&instance->bulk_waiter_list_mutex);
vchiq_log_info(vchiq_arm_log_level,
- "saved bulk_waiter %x for pid %d",
- (unsigned int)waiter, current->pid);
+ "saved bulk_waiter %p for pid %d",
+ waiter, current->pid);
if (copy_to_user((void __user *)
&(((VCHIQ_QUEUE_BULK_TRANSFER_T __user *)
@@ -826,9 +826,9 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
if (args.msgbufsize < msglen) {
vchiq_log_error(
vchiq_arm_log_level,
- "header %x: msgbufsize"
+ "header %p: msgbufsize"
" %x < msglen %x",
- (unsigned int)header,
+ header,
args.msgbufsize,
msglen);
WARN(1, "invalid message "
@@ -980,8 +980,8 @@ vchiq_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
ret = -EFAULT;
} else {
vchiq_log_error(vchiq_arm_log_level,
- "header %x: bufsize %x < size %x",
- (unsigned int)header, args.bufsize,
+ "header %p: bufsize %x < size %x",
+ header, args.bufsize,
header->size);
WARN(1, "invalid size\n");
ret = -EMSGSIZE;
@@ -1284,9 +1284,9 @@ vchiq_release(struct inode *inode, struct file *file)
list);
list_del(pos);
vchiq_log_info(vchiq_arm_log_level,
- "bulk_waiter - cleaned up %x "
+ "bulk_waiter - cleaned up %p "
"for pid %d",
- (unsigned int)waiter, waiter->pid);
+ waiter, waiter->pid);
kfree(waiter);
}
}
@@ -1385,9 +1385,9 @@ vchiq_dump_platform_instances(void *dump_context)
instance = service->instance;
if (instance && !instance->mark) {
len = snprintf(buf, sizeof(buf),
- "Instance %x: pid %d,%s completions "
+ "Instance %p: pid %d,%s completions "
"%d/%d",
- (unsigned int)instance, instance->pid,
+ instance, instance->pid,
instance->connected ? " connected, " :
"",
instance->completion_insert -
@@ -1415,8 +1415,8 @@ vchiq_dump_platform_service_state(void *dump_context, VCHIQ_SERVICE_T *service)
char buf[80];
int len;
- len = snprintf(buf, sizeof(buf), " instance %x",
- (unsigned int)service->instance);
+ len = snprintf(buf, sizeof(buf), " instance %p",
+ service->instance);
if ((service->base.callback == service_callback) &&
user_service->is_vchi) {
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index 2c98da4307df..93a6ac75791f 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -380,9 +380,9 @@ make_service_callback(VCHIQ_SERVICE_T *service, VCHIQ_REASON_T reason,
VCHIQ_HEADER_T *header, void *bulk_userdata)
{
VCHIQ_STATUS_T status;
- vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %x, %x)",
+ vchiq_log_trace(vchiq_core_log_level, "%d: callback:%d (%s, %p, %p)",
service->state->id, service->localport, reason_names[reason],
- (unsigned int)header, (unsigned int)bulk_userdata);
+ header, bulk_userdata);
status = service->base.callback(reason, header, service->handle,
bulk_userdata);
if (status == VCHIQ_ERROR) {
@@ -626,8 +626,8 @@ process_free_queue(VCHIQ_STATE_T *state)
char *data = (char *)SLOT_DATA_FROM_INDEX(state, slot_index);
int data_found = 0;
- vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=%x %x %x",
- state->id, slot_index, (unsigned int)data,
+ vchiq_log_trace(vchiq_core_log_level, "%d: pfq %d=%p %x %x",
+ state->id, slot_index, data,
local->slot_queue_recycle, slot_queue_available);
/* Initialise the bitmask for services which have used this
@@ -661,13 +661,13 @@ process_free_queue(VCHIQ_STATE_T *state)
vchiq_log_error(vchiq_core_log_level,
"service %d "
"message_use_count=%d "
- "(header %x, msgid %x, "
+ "(header %p, msgid %x, "
"header->msgid %x, "
"header->size %x)",
port,
service_quota->
message_use_count,
- (unsigned int)header, msgid,
+ header, msgid,
header->msgid,
header->size);
WARN(1, "invalid message use count\n");
@@ -690,24 +690,24 @@ process_free_queue(VCHIQ_STATE_T *state)
up(&service_quota->quota_event);
vchiq_log_trace(
vchiq_core_log_level,
- "%d: pfq:%d %x@%x - "
+ "%d: pfq:%d %x@%p - "
"slot_use->%d",
state->id, port,
header->size,
- (unsigned int)header,
+ header,
count - 1);
} else {
vchiq_log_error(
vchiq_core_log_level,
"service %d "
"slot_use_count"
- "=%d (header %x"
+ "=%d (header %p"
", msgid %x, "
"header->msgid"
" %x, header->"
"size %x)",
port, count,
- (unsigned int)header,
+ header,
msgid,
header->msgid,
header->size);
@@ -721,9 +721,9 @@ process_free_queue(VCHIQ_STATE_T *state)
pos += calc_stride(header->size);
if (pos > VCHIQ_SLOT_SIZE) {
vchiq_log_error(vchiq_core_log_level,
- "pfq - pos %x: header %x, msgid %x, "
+ "pfq - pos %x: header %p, msgid %x, "
"header->msgid %x, header->size %x",
- pos, (unsigned int)header, msgid,
+ pos, header, msgid,
header->msgid, header->size);
WARN(1, "invalid slot position\n");
}
@@ -868,10 +868,10 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
int slot_use_count;
vchiq_log_info(vchiq_core_log_level,
- "%d: qm %s@%x,%x (%d->%d)",
+ "%d: qm %s@%p,%x (%d->%d)",
state->id,
msg_type_str(VCHIQ_MSG_TYPE(msgid)),
- (unsigned int)header, size,
+ header, size,
VCHIQ_MSG_SRCPORT(msgid),
VCHIQ_MSG_DSTPORT(msgid));
@@ -936,9 +936,9 @@ queue_message(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size);
} else {
vchiq_log_info(vchiq_core_log_level,
- "%d: qm %s@%x,%x (%d->%d)", state->id,
+ "%d: qm %s@%p,%x (%d->%d)", state->id,
msg_type_str(VCHIQ_MSG_TYPE(msgid)),
- (unsigned int)header, size,
+ header, size,
VCHIQ_MSG_SRCPORT(msgid),
VCHIQ_MSG_DSTPORT(msgid));
if (size != 0) {
@@ -1021,9 +1021,9 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
int i, pos;
vchiq_log_info(vchiq_sync_log_level,
- "%d: qms %s@%x,%x (%d->%d)", state->id,
+ "%d: qms %s@%p,%x (%d->%d)", state->id,
msg_type_str(VCHIQ_MSG_TYPE(msgid)),
- (unsigned int)header, size,
+ header, size,
VCHIQ_MSG_SRCPORT(msgid),
VCHIQ_MSG_DSTPORT(msgid));
@@ -1053,9 +1053,9 @@ queue_message_sync(VCHIQ_STATE_T *state, VCHIQ_SERVICE_T *service,
VCHIQ_SERVICE_STATS_ADD(service, ctrl_tx_bytes, size);
} else {
vchiq_log_info(vchiq_sync_log_level,
- "%d: qms %s@%x,%x (%d->%d)", state->id,
+ "%d: qms %s@%p,%x (%d->%d)", state->id,
msg_type_str(VCHIQ_MSG_TYPE(msgid)),
- (unsigned int)header, size,
+ header, size,
VCHIQ_MSG_SRCPORT(msgid),
VCHIQ_MSG_DSTPORT(msgid));
if (size != 0) {
@@ -1356,26 +1356,26 @@ resolve_bulks(VCHIQ_SERVICE_T *service, VCHIQ_BULK_QUEUE_T *queue)
"Send Bulk to" : "Recv Bulk from";
if (bulk->actual != VCHIQ_BULK_ACTUAL_ABORTED)
vchiq_log_info(SRVTRACE_LEVEL(service),
- "%s %c%c%c%c d:%d len:%d %x<->%x",
+ "%s %c%c%c%c d:%d len:%d %p<->%p",
header,
VCHIQ_FOURCC_AS_4CHARS(
service->base.fourcc),
service->remoteport,
bulk->size,
- (unsigned int)bulk->data,
- (unsigned int)bulk->remote_data);
+ bulk->data,
+ bulk->remote_data);
else
vchiq_log_info(SRVTRACE_LEVEL(service),
"%s %c%c%c%c d:%d ABORTED - tx len:%d,"
- " rx len:%d %x<->%x",
+ " rx len:%d %p<->%p",
header,
VCHIQ_FOURCC_AS_4CHARS(
service->base.fourcc),
service->remoteport,
bulk->size,
bulk->remote_size,
- (unsigned int)bulk->data,
- (unsigned int)bulk->remote_data);
+ bulk->data,
+ bulk->remote_data);
}
vchiq_complete_bulk(bulk);
@@ -1511,8 +1511,8 @@ parse_open(VCHIQ_STATE_T *state, VCHIQ_HEADER_T *header)
fourcc = payload->fourcc;
vchiq_log_info(vchiq_core_log_level,
- "%d: prs OPEN@%x (%d->'%c%c%c%c')",
- state->id, (unsigned int)header,
+ "%d: prs OPEN@%p (%d->'%c%c%c%c')",
+ state->id, header,
localport,
VCHIQ_FOURCC_AS_4CHARS(fourcc));
@@ -1684,20 +1684,20 @@ parse_rx_slots(VCHIQ_STATE_T *state)
remoteport);
if (service)
vchiq_log_warning(vchiq_core_log_level,
- "%d: prs %s@%x (%d->%d) - "
+ "%d: prs %s@%p (%d->%d) - "
"found connected service %d",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport,
service->localport);
}
if (!service) {
vchiq_log_error(vchiq_core_log_level,
- "%d: prs %s@%x (%d->%d) - "
+ "%d: prs %s@%p (%d->%d) - "
"invalid/closed service %d",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport, localport);
goto skip_message;
}
@@ -1726,9 +1726,9 @@ parse_rx_slots(VCHIQ_STATE_T *state)
if (((unsigned int)header & VCHIQ_SLOT_MASK) + calc_stride(size)
> VCHIQ_SLOT_SIZE) {
vchiq_log_error(vchiq_core_log_level,
- "header %x (msgid %x) - size %x too big for "
+ "header %p (msgid %x) - size %x too big for "
"slot",
- (unsigned int)header, (unsigned int)msgid,
+ header, (unsigned int)msgid,
(unsigned int)size);
WARN(1, "oversized for slot\n");
}
@@ -1747,8 +1747,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
service->peer_version = payload->version;
}
vchiq_log_info(vchiq_core_log_level,
- "%d: prs OPENACK@%x,%x (%d->%d) v:%d",
- state->id, (unsigned int)header, size,
+ "%d: prs OPENACK@%p,%x (%d->%d) v:%d",
+ state->id, header, size,
remoteport, localport, service->peer_version);
if (service->srvstate ==
VCHIQ_SRVSTATE_OPENING) {
@@ -1765,8 +1765,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
WARN_ON(size != 0); /* There should be no data */
vchiq_log_info(vchiq_core_log_level,
- "%d: prs CLOSE@%x (%d->%d)",
- state->id, (unsigned int)header,
+ "%d: prs CLOSE@%p (%d->%d)",
+ state->id, header,
remoteport, localport);
mark_service_closing_internal(service, 1);
@@ -1783,8 +1783,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
break;
case VCHIQ_MSG_DATA:
vchiq_log_info(vchiq_core_log_level,
- "%d: prs DATA@%x,%x (%d->%d)",
- state->id, (unsigned int)header, size,
+ "%d: prs DATA@%p,%x (%d->%d)",
+ state->id, header, size,
remoteport, localport);
if ((service->remoteport == remoteport)
@@ -1808,8 +1808,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
break;
case VCHIQ_MSG_CONNECT:
vchiq_log_info(vchiq_core_log_level,
- "%d: prs CONNECT@%x",
- state->id, (unsigned int)header);
+ "%d: prs CONNECT@%p",
+ state->id, header);
state->version_common = ((VCHIQ_SLOT_ZERO_T *)
state->slot_data)->version;
up(&state->connect);
@@ -1843,12 +1843,12 @@ parse_rx_slots(VCHIQ_STATE_T *state)
wmb();
vchiq_log_info(vchiq_core_log_level,
- "%d: prs %s@%x (%d->%d) %x@%x",
+ "%d: prs %s@%p (%d->%d) %x@%p",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport,
bulk->remote_size,
- (unsigned int)bulk->remote_data);
+ bulk->remote_data);
queue->remote_insert++;
@@ -1901,10 +1901,10 @@ parse_rx_slots(VCHIQ_STATE_T *state)
if ((int)(queue->remote_insert -
queue->local_insert) >= 0) {
vchiq_log_error(vchiq_core_log_level,
- "%d: prs %s@%x (%d->%d) "
+ "%d: prs %s@%p (%d->%d) "
"unexpected (ri=%d,li=%d)",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport,
queue->remote_insert,
queue->local_insert);
@@ -1921,11 +1921,11 @@ parse_rx_slots(VCHIQ_STATE_T *state)
queue->remote_insert++;
vchiq_log_info(vchiq_core_log_level,
- "%d: prs %s@%x (%d->%d) %x@%x",
+ "%d: prs %s@%p (%d->%d) %x@%p",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport,
- bulk->actual, (unsigned int)bulk->data);
+ bulk->actual, bulk->data);
vchiq_log_trace(vchiq_core_log_level,
"%d: prs:%d %cx li=%x ri=%x p=%x",
@@ -1947,14 +1947,14 @@ parse_rx_slots(VCHIQ_STATE_T *state)
break;
case VCHIQ_MSG_PADDING:
vchiq_log_trace(vchiq_core_log_level,
- "%d: prs PADDING@%x,%x",
- state->id, (unsigned int)header, size);
+ "%d: prs PADDING@%p,%x",
+ state->id, header, size);
break;
case VCHIQ_MSG_PAUSE:
/* If initiated, signal the application thread */
vchiq_log_trace(vchiq_core_log_level,
- "%d: prs PAUSE@%x,%x",
- state->id, (unsigned int)header, size);
+ "%d: prs PAUSE@%p,%x",
+ state->id, header, size);
if (state->conn_state == VCHIQ_CONNSTATE_PAUSED) {
vchiq_log_error(vchiq_core_log_level,
"%d: PAUSE received in state PAUSED",
@@ -1977,8 +1977,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
break;
case VCHIQ_MSG_RESUME:
vchiq_log_trace(vchiq_core_log_level,
- "%d: prs RESUME@%x,%x",
- state->id, (unsigned int)header, size);
+ "%d: prs RESUME@%p,%x",
+ state->id, header, size);
/* Release the slot mutex */
mutex_unlock(&state->slot_mutex);
if (state->is_master)
@@ -1999,8 +1999,8 @@ parse_rx_slots(VCHIQ_STATE_T *state)
default:
vchiq_log_error(vchiq_core_log_level,
- "%d: prs invalid msgid %x@%x,%x",
- state->id, msgid, (unsigned int)header, size);
+ "%d: prs invalid msgid %x@%p,%x",
+ state->id, msgid, header, size);
WARN(1, "invalid message\n");
break;
}
@@ -2165,10 +2165,10 @@ sync_func(void *v)
if (!service) {
vchiq_log_error(vchiq_sync_log_level,
- "%d: sf %s@%x (%d->%d) - "
+ "%d: sf %s@%p (%d->%d) - "
"invalid/closed service %d",
state->id, msg_type_str(type),
- (unsigned int)header,
+ header,
remoteport, localport, localport);
release_message_sync(state, header);
continue;
@@ -2199,8 +2199,8 @@ sync_func(void *v)
service->peer_version = payload->version;
}
vchiq_log_info(vchiq_sync_log_level,
- "%d: sf OPENACK@%x,%x (%d->%d) v:%d",
- state->id, (unsigned int)header, size,
+ "%d: sf OPENACK@%p,%x (%d->%d) v:%d",
+ state->id, header, size,
remoteport, localport, service->peer_version);
if (service->srvstate == VCHIQ_SRVSTATE_OPENING) {
service->remoteport = remoteport;
@@ -2214,8 +2214,8 @@ sync_func(void *v)
case VCHIQ_MSG_DATA:
vchiq_log_trace(vchiq_sync_log_level,
- "%d: sf DATA@%x,%x (%d->%d)",
- state->id, (unsigned int)header, size,
+ "%d: sf DATA@%p,%x (%d->%d)",
+ state->id, header, size,
remoteport, localport);
if ((service->remoteport == remoteport) &&
@@ -2234,8 +2234,8 @@ sync_func(void *v)
default:
vchiq_log_error(vchiq_sync_log_level,
- "%d: sf unexpected msgid %x@%x,%x",
- state->id, msgid, (unsigned int)header, size);
+ "%d: sf unexpected msgid %x@%p,%x",
+ state->id, msgid, header, size);
release_message_sync(state, header);
break;
}
@@ -2324,8 +2324,8 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
if (slot_zero->magic != VCHIQ_MAGIC) {
vchiq_loud_error_header();
vchiq_loud_error("Invalid VCHIQ magic value found.");
- vchiq_loud_error("slot_zero=%x: magic=%x (expected %x)",
- (unsigned int)slot_zero, slot_zero->magic, VCHIQ_MAGIC);
+ vchiq_loud_error("slot_zero=%p: magic=%x (expected %x)",
+ slot_zero, slot_zero->magic, VCHIQ_MAGIC);
vchiq_loud_error_footer();
return VCHIQ_ERROR;
}
@@ -2333,9 +2333,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
if (slot_zero->version < VCHIQ_VERSION_MIN) {
vchiq_loud_error_header();
vchiq_loud_error("Incompatible VCHIQ versions found.");
- vchiq_loud_error("slot_zero=%x: VideoCore version=%d "
+ vchiq_loud_error("slot_zero=%p: VideoCore version=%d "
"(minimum %d)",
- (unsigned int)slot_zero, slot_zero->version,
+ slot_zero, slot_zero->version,
VCHIQ_VERSION_MIN);
vchiq_loud_error("Restart with a newer VideoCore image.");
vchiq_loud_error_footer();
@@ -2345,9 +2345,9 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
if (VCHIQ_VERSION < slot_zero->version_min) {
vchiq_loud_error_header();
vchiq_loud_error("Incompatible VCHIQ versions found.");
- vchiq_loud_error("slot_zero=%x: version=%d (VideoCore "
+ vchiq_loud_error("slot_zero=%p: version=%d (VideoCore "
"minimum %d)",
- (unsigned int)slot_zero, VCHIQ_VERSION,
+ slot_zero, VCHIQ_VERSION,
slot_zero->version_min);
vchiq_loud_error("Restart with a newer kernel.");
vchiq_loud_error_footer();
@@ -2360,25 +2360,25 @@ vchiq_init_state(VCHIQ_STATE_T *state, VCHIQ_SLOT_ZERO_T *slot_zero,
(slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE)) {
vchiq_loud_error_header();
if (slot_zero->slot_zero_size != sizeof(VCHIQ_SLOT_ZERO_T))
- vchiq_loud_error("slot_zero=%x: slot_zero_size=%x "
+ vchiq_loud_error("slot_zero=%p: slot_zero_size=%x "
"(expected %x)",
- (unsigned int)slot_zero,
+ slot_zero,
slot_zero->slot_zero_size,
sizeof(VCHIQ_SLOT_ZERO_T));
if (slot_zero->slot_size != VCHIQ_SLOT_SIZE)
- vchiq_loud_error("slot_zero=%x: slot_size=%d "
+ vchiq_loud_error("slot_zero=%p: slot_size=%d "
"(expected %d",
- (unsigned int)slot_zero, slot_zero->slot_size,
+ slot_zero, slot_zero->slot_size,
VCHIQ_SLOT_SIZE);
if (slot_zero->max_slots != VCHIQ_MAX_SLOTS)
- vchiq_loud_error("slot_zero=%x: max_slots=%d "
+ vchiq_loud_error("slot_zero=%p: max_slots=%d "
"(expected %d)",
- (unsigned int)slot_zero, slot_zero->max_slots,
+ slot_zero, slot_zero->max_slots,
VCHIQ_MAX_SLOTS);
if (slot_zero->max_slots_per_side != VCHIQ_MAX_SLOTS_PER_SIDE)
- vchiq_loud_error("slot_zero=%x: max_slots_per_side=%d "
+ vchiq_loud_error("slot_zero=%p: max_slots_per_side=%d "
"(expected %d)",
- (unsigned int)slot_zero,
+ slot_zero,
slot_zero->max_slots_per_side,
VCHIQ_MAX_SLOTS_PER_SIDE);
vchiq_loud_error_footer();
@@ -2756,18 +2756,18 @@ release_service_messages(VCHIQ_SERVICE_T *service)
if ((port == service->localport) &&
(msgid & VCHIQ_MSGID_CLAIMED)) {
vchiq_log_info(vchiq_core_log_level,
- " fsi - hdr %x",
- (unsigned int)header);
+ " fsi - hdr %p",
+ header);
release_slot(state, slot_info, header,
NULL);
}
pos += calc_stride(header->size);
if (pos > VCHIQ_SLOT_SIZE) {
vchiq_log_error(vchiq_core_log_level,
- "fsi - pos %x: header %x, "
+ "fsi - pos %x: header %p, "
"msgid %x, header->msgid %x, "
"header->size %x",
- pos, (unsigned int)header,
+ pos, header,
msgid, header->msgid,
header->size);
WARN(1, "invalid slot position\n");
@@ -3341,10 +3341,10 @@ vchiq_bulk_transfer(VCHIQ_SERVICE_HANDLE_T handle,
wmb();
vchiq_log_info(vchiq_core_log_level,
- "%d: bt (%d->%d) %cx %x@%x %x",
+ "%d: bt (%d->%d) %cx %x@%p %p",
state->id,
service->localport, service->remoteport, dir_char,
- size, (unsigned int)bulk->data, (unsigned int)userdata);
+ size, bulk->data, userdata);
/* The slot mutex must be held when the service is being closed, so
claim it here to ensure that isn't happening */
@@ -3691,12 +3691,12 @@ vchiq_dump_state(void *dump_context, VCHIQ_STATE_T *state)
vchiq_dump(dump_context, buf, len + 1);
len = snprintf(buf, sizeof(buf),
- " tx_pos=%x(@%x), rx_pos=%x(@%x)",
+ " tx_pos=%x(@%p), rx_pos=%x(@%p)",
state->local->tx_pos,
- (uint32_t)state->tx_data +
+ state->tx_data +
(state->local_tx_pos & VCHIQ_SLOT_MASK),
state->rx_pos,
- (uint32_t)state->rx_data +
+ state->rx_data +
(state->rx_pos & VCHIQ_SLOT_MASK));
vchiq_dump(dump_context, buf, len + 1);
--
2.9.3
^ permalink raw reply related
* [PATCH 1/5] staging/vchi: Fix build error in debugfs ops on aarch64.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017194406.1080-1-eric@anholt.net>
file_operations.write returns a ssize_t, which worked out fine on 32
bit but errors out on 64 bit.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
index 7e032130d967..f07cd4448ddf 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_debugfs.c
@@ -120,7 +120,7 @@ static int debugfs_log_open(struct inode *inode, struct file *file)
return single_open(file, debugfs_log_show, inode->i_private);
}
-static int debugfs_log_write(struct file *file,
+static ssize_t debugfs_log_write(struct file *file,
const char __user *buffer,
size_t count, loff_t *ppos)
{
@@ -229,7 +229,7 @@ static int debugfs_trace_open(struct inode *inode, struct file *file)
return single_open(file, debugfs_trace_show, inode->i_private);
}
-static int debugfs_trace_write(struct file *file,
+static ssize_t debugfs_trace_write(struct file *file,
const char __user *buffer,
size_t count, loff_t *ppos)
{
--
2.9.3
^ permalink raw reply related
* [PATCH 0/5] staging/vchi: Start on 64-bit cleanup, TODO file.
From: Eric Anholt @ 2016-10-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
Here's a little cleanup of VCHI this morning, working toward building
on aarch64 (not there yet) and adding some notes on what I think we
need to do with the driver.
Eric Anholt (5):
staging/vchi: Fix build error in debugfs ops on aarch64.
staging/vchi: Fix build warnings when formatting pointers on aarch64.
staging/vchi: Fix some pointer math for 64-bit.
staging/vchi: Add a TODO file of things I know we need to deal with.
MAINTAINERS: Add the staging vchiq driver as a bcm2835 responsibility.
MAINTAINERS | 1 +
drivers/staging/vc04_services/interface/vchi/TODO | 50 ++++++
.../interface/vchiq_arm/vchiq_2835_arm.c | 15 +-
.../vc04_services/interface/vchiq_arm/vchiq_arm.c | 32 ++--
.../vc04_services/interface/vchiq_arm/vchiq_core.c | 183 +++++++++++----------
.../interface/vchiq_arm/vchiq_debugfs.c | 4 +-
6 files changed, 168 insertions(+), 117 deletions(-)
create mode 100644 drivers/staging/vc04_services/interface/vchi/TODO
--
2.9.3
^ permalink raw reply
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Ard Biesheuvel @ 2016-10-17 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017183806.GG5601@arm.com>
On 17 October 2016 at 19:38, Will Deacon <will.deacon@arm.com> wrote:
> Hi all,
>
> I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
> believe that the new compiler behaviour at the heart of the problem
> has the potential to affect other architectures and other pieces of
> kernel code relying on dead-code elimination to remove deliberately
> undefined functions.
>
> The failure looks like:
>
> | drivers/built-in.o: In function `armada_3700_add_composite_clk':
> |
> | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:
> | undefined reference to `____ilog2_NaN'
> |
> | linux/drivers/clk/mvebu/armada-37xx-periph.c:351:(.text+0xc72e0):
> | relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> | `____ilog2_NaN'
> |
> | make: *** [vmlinux] Error 1
>
> and if we look at the source for armada_3700_add_composite_clk, we see
> that this is caused by:
>
> int table_size = 0;
>
> rate->reg = reg + (u64)rate->reg;
> for (clkt = rate->table; clkt->div; clkt++)
> table_size++;
> rate->width = order_base_2(table_size);
>
> order_base_2 calls ilog2, which has the ____ilog2_NaN call:
>
> #define ilog2(n) \
> ( \
> __builtin_constant_p(n) ? ( \
> (n) < 1 ? ____ilog2_NaN() : \
>
> This is because we're in a curious case where GCC has emitted a
> special-cased version of armada_3700_add_composite_clk, with table_size
> effectively constant-folded as 0. Whilst we shouldn't see this in a
> non-buggy kernel (hence the deliberate call to the undefined function
> ____ilog2_NaN), it means that the final link fails because we have a
> ____ilog2_NaN in the code, with a runtime check on table_size.
>
This is indeed an unintended side effect, but I would not call it
weird behaviour at all. The code in its current form does not handle
the case where it could end up passing 0 into order_base_2(), and we
simply need to handle that case. If order_base_2() is not defined for
input 0, it should BUG() in that case, and the associated
__builtin_unreachable() should prevent the special version from being
emitted. If order_base_2() is defined for input 0, it should not
invoke ilog2() with that argument, and the problem should go away as
well.
--
Ard.
> In other words, __builtin_constant_p appears to be weaker than we've
> been assuming. Talking to the compiler guys here, this is due to the
> "jump-threading" optimisation pass, so the patch below disables that.
>
> A simpler example is:
>
> int foo();
> int bar();
>
> int count(int *argc)
> {
> int table_size = 0;
>
> for (; *argc; argc++)
> table_size++;
>
> if (__builtin_constant_p(table_size))
> return table_size == 0 ? foo() : bar();
>
> return bar();
> }
>
> which compiles to:
>
> count:
> ldr w0, [x0]
> cbz w0, .L4
> b bar
> .p2align 3
> .L4:
> b foo
>
> and, with the "optimisation" disabled:
>
> count:
> b bar
>
> Thoughts? It feels awfully fragile disabling passes like this, but with
> GCC transforming the code like this, I can't immediately think of a way
> to preserve the intended behaviour of the code.
>
> Will
>
> --->8
>
> diff --git a/Makefile b/Makefile
> index 512e47a53e9a..750873d6d11e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -641,6 +641,11 @@ endif
> # Tell gcc to never replace conditional load with a non-conditional one
> KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
>
> +# Stop gcc from converting switches into a form that defeats dead code
> +# elimination and can subsequently lead to calls to intentionally
> +# undefined functions appearing in the final link.
> +KBUILD_CFLAGS += $(call cc-option,--param=max-fsm-thread-path-insns=1)
> +
> include scripts/Makefile.gcc-plugins
>
> ifdef CONFIG_READABLE_ASM
^ permalink raw reply
* [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version
From: Krzysztof Kozlowski @ 2016-10-17 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0326b619-3af5-e4ef-2251-16e60105ef67@soulik.info>
On Tue, Oct 18, 2016 at 01:57:47AM +0800, ayaka wrote:
>
>
> On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:
> >On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:
> >>The TOPEET itop is a samsung exnynos 4412 core board, which have
> >>two package versions. This patch add the support for SCP version.
> >>
> >>Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
> >>PMIC. The future features are in the based board. Also MFC and
> >>watchdog have been enabled.
> >>
> >>Signed-off-by: Randy Li <ayaka@soulik.info>
> >>---
> >> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++++++++++
> >> 1 file changed, 501 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> >I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
> >Really, after v8? The code must compile (v6 did not compile...), there
> >should be no warnings from smatch, sparse and checkpatch (only the last
> >one is applicable for DTS). Unless of course checkpatch would be
> >wrong... but in this case it is correct. You did not follow coding
> >style:
> >
> >WARNING: please, no spaces at the start of a line
> >#134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
> >+ devfreq = <&bus_leftbus>;$
> >
> >ERROR: code indent should use tabs where possible
> >#135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
> >+ status = "okay";$
> Oh, it is a copy mistake, the copy operation makes the original tab becomes
> spaces.
> Should I send a new version to correct them?
Yes, please send new version. The DTS (code) itself looked fine, so only
the checkpatch issues are remaining.
BTW, why are you copying the files? Even if you have multiple trees
(like product/vendor kernel and mainline) then you can easily move
patches with cherry-pick, apply or am commands. Then finally just 'git
format-patch -2 -v9' and 'git send-email'.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] hwrng: meson: Fix module autoload for OF registration
From: Javier Martinez Canillas @ 2016-10-17 19:40 UTC (permalink / raw)
To: linux-arm-kernel
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
After this patch:
$ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
alias: platform:meson-rng
alias: of:N*T*Camlogic,meson-rngC*
alias: of:N*T*Camlogic,meson-rng
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
drivers/char/hw_random/meson-rng.c | 1 +
drivers/char/tpm/Kconfig | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 58bef39f7286..51864a509be7 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -110,6 +110,7 @@ static const struct of_device_id meson_rng_of_match[] = {
{ .compatible = "amlogic,meson-rng", },
{},
};
+MODULE_DEVICE_TABLE(of, meson_rng_of_match);
static struct platform_driver meson_rng_driver = {
.probe = meson_rng_probe,
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index 9faa0b1e7766..982ed2fe927c 100644
--- a/drivers/char/tpm/Kconfig
+++ b/drivers/char/tpm/Kconfig
@@ -32,7 +32,7 @@ config TCG_TIS_CORE
config TCG_TIS
tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO Interface"
- depends on X86
+ depends on X86 || COMPILE_TEST
select TCG_TIS_CORE
---help---
If you have a TPM security chip that is compliant with the
--
2.7.4
^ permalink raw reply related
* Regression: usb serial gadget on sama5d3 broken
From: Alexandre Belloni @ 2016-10-17 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <621565bc-2fa0-bbd1-80cd-6c9b2a494faa@axentia.se>
On 17/10/2016 at 19:50:48 +0200, Peter Rosin wrote :
> On 2016-10-17 16:54, Nicolas Ferre wrote:
> > Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
> >> Hi!
> >>
> >> I'm suffering from a regression while using the usb gadget port on the
> >> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
> >>
> >> I get this message when I try to connect:
> >> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
> >>
> >> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
> >> USB endpoint nodes".
> >>
> >> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
> >> although that doesn't look like the best of fixes...
> >>
> >> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
> >> somewhere in the overlayfs area. I hope I will never ever need to bisect
> >> in the v4.6..v4.7 area again. This was the second time, the first time
> >> I was chasing a gpio interrupt bug, but I never found out what was wrong
> >> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
> >> was bad, it was just too painful to look for things that already seemed
> >> fixed.
> >
> > I guess that you are referring to the regression listed here:
> > https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
> >
> > The patch is available and will hopefully land in an official kernel
> > soon (4.8.1) as said by Felipe and Greg.
> >
> > Sorry for the inconvenience. Best regards,
>
> Ok, I tried "usb: gadget: udc: atmel: fix endpoint name" and it fixes
> things for me too. But shouldn't the memory for the now dynamic name be
> allocated with devm_kasprintf instead of that plain kasprint? If you
> are pedantic...
>
That wouldn't be a bad idea.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-10-17 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161006161114.GH22012@rric.localdomain>
Mark, Will, any opinion here?
Thanks,
-Robert
On 06.10.16 18:11:14, Robert Richter wrote:
> Ard,
>
> thank you for your answer and you explanation.
>
> On 06.10.16 11:00:33, Ard Biesheuvel wrote:
> > On 6 October 2016 at 10:52, Robert Richter <rrichter@cavium.com> wrote:
> > > There is a memory setup problem on ThunderX systems with certain
> > > memory configurations. The symptom is
> > >
> > > kernel BUG at mm/page_alloc.c:1848!
> > >
> > > This happens for some configs with 64k page size enabled. The bug
> > > triggers for page zones with some pages in the zone not assigned to
> > > this particular zone. In my case some pages that are marked as nomap
> > > were not reassigned to the new zone of node 1, so those are still
> > > assigned to node 0.
> > >
> > > The reason for the mis-configuration is a change in pfn_valid() which
> > > reports pages marked nomap as invalid:
> > >
> > > 68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
> > >
> >
> > These pages are owned by the firmware, which may map it with
> > attributes that conflict with the attributes we use for the linear
> > mapping. This means they should not be covered by the linear mapping.
> >
> > > This causes pages marked as nomap being no long reassigned to the new
> > > zone in memmap_init_zone() by calling __init_single_pfn().
> > >
> >
> > This sounds like the root cause of your issue. Could we not fix that instead?
>
> Yes, this is proposal b) from my last mail that would work too: I
> implemented an arm64 private early_pfn_valid() function that uses
> memblock_is_memory() to setup all pages of a zone. Though, I think
> this is the wrong way and thus I prefer this patch instead. I see
> serveral reasons for this:
>
> Inconsistent use of struct *page, it is initialized but never used
> again.
>
> Other archs only do a basic range check in pfn_valid(), the default
> implementation just returns if the whole section is valid. As I
> understand the code, if the mem range is not aligned to the section,
> then there will be pfn's in the section that don't have physical mem
> attached. The page is then just initialized, it's not marked reserved
> nor the refcount is non-zero. It is then simply not used. This is how
> no-map pages should be handled too.
>
> I think pfn_valid() is just a quick check if the pfn's struct *page
> can be used. There is a good description for this in include/linux/
> mmzone.h. So there can be memory holes that have a valid pfn.
>
> If the no-map memory needs special handling, then additional checks
> need to be added to the particular code (as in ioremap.c). It's imo
> wrong to (mis-)use pfn_valid for that.
>
> Variant b) involves generic mm code to fix it for arm64, this patch is
> an arm64 change only. This makes it harder to get a fix for it.
> (Though maybe only a problem of patch logistics.)
>
> >
> > > Fixing this by restoring the old behavior of pfn_valid() to use
> > > memblock_is_memory().
> >
> > This is incorrect imo. In general, pfn_valid() means ordinary memory
> > covered by the linear mapping and the struct page array. Returning
> > reserved ranges that the kernel should not even touch only to please
> > the NUMA code seems like an inappropriate way to deal with this issue.
>
> As said above, it is not marked as reserved, it is treated like
> non-existing memory.
>
> This has been observed for non-numa kernels too and can happen for
> each zone that is only partly initialized.
>
> I think the patch addresses your concerns. I can't see there the
> kernel uses memory marked as nomap in a wrong way.
>
> Thanks,
>
> -Robert
>
> >
> > > Also changing users of pfn_valid() in arm64 code
> > > to use memblock_is_map_memory() where necessary. This only affects
> > > code in ioremap.c. The code in mmu.c still can use the new version of
> > > pfn_valid().
> > >
> > > Should be marked stable v4.5..
> > >
> > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > ---
> > > arch/arm64/mm/init.c | 2 +-
> > > arch/arm64/mm/ioremap.c | 5 +++--
> > > 2 files changed, 4 insertions(+), 3 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clk: qoriq: Don't allow CPU clocks higher than starting value
From: Scott Wood @ 2016-10-17 18:42 UTC (permalink / raw)
To: linux-arm-kernel
The boot-time frequency of a CPU is considered its rated maximum, as we
have no other source of such information. However, this was previously
only used for chips with 80% restrictions on secondary PLLs. This
usually wasn't a problem because most chips/configs boot with a divider
of /1, with other dividers being used only for dynamic frequency
reduction. However, at least one config (LS1021A at less than 1 GHz)
uses a different divider for top speed. This was causing cpufreq to set
a frequency beyond the chip's rated speed.
This is fixed by applying a 100%-of-initial-speed limit to all CPU PLLs,
similar to the existing 80% limit that only applied to some.
Signed-off-by: Scott Wood <oss@buserror.net>
Cc: stable at vger.kernel.org
---
drivers/clk/clk-qoriq.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c
index 20b1055..80ae2a5 100644
--- a/drivers/clk/clk-qoriq.c
+++ b/drivers/clk/clk-qoriq.c
@@ -700,6 +700,7 @@ static struct clk * __init create_mux_common(struct clockgen *cg,
struct mux_hwclock *hwc,
const struct clk_ops *ops,
unsigned long min_rate,
+ unsigned long max_rate,
unsigned long pct80_rate,
const char *fmt, int idx)
{
@@ -728,6 +729,8 @@ static struct clk * __init create_mux_common(struct clockgen *cg,
continue;
if (rate < min_rate)
continue;
+ if (rate > max_rate)
+ continue;
parent_names[j] = div->name;
hwc->parent_to_clksel[j] = i;
@@ -759,7 +762,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
struct mux_hwclock *hwc;
const struct clockgen_pll_div *div;
unsigned long plat_rate, min_rate;
- u64 pct80_rate;
+ u64 max_rate, pct80_rate;
u32 clksel;
hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
@@ -787,8 +790,8 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
return NULL;
}
- pct80_rate = clk_get_rate(div->clk);
- pct80_rate *= 8;
+ max_rate = clk_get_rate(div->clk);
+ pct80_rate = max_rate * 8;
do_div(pct80_rate, 10);
plat_rate = clk_get_rate(cg->pll[PLATFORM_PLL].div[PLL_DIV1].clk);
@@ -798,7 +801,7 @@ static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
else
min_rate = plat_rate / 2;
- return create_mux_common(cg, hwc, &cmux_ops, min_rate,
+ return create_mux_common(cg, hwc, &cmux_ops, min_rate, max_rate,
pct80_rate, "cg-cmux%d", idx);
}
@@ -813,7 +816,7 @@ static struct clk * __init create_one_hwaccel(struct clockgen *cg, int idx)
hwc->reg = cg->regs + 0x20 * idx + 0x10;
hwc->info = cg->info.hwaccel[idx];
- return create_mux_common(cg, hwc, &hwaccel_ops, 0, 0,
+ return create_mux_common(cg, hwc, &hwaccel_ops, 0, ULONG_MAX, 0,
"cg-hwaccel%d", idx);
}
--
2.7.4
^ permalink raw reply related
* Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
From: Will Deacon @ 2016-10-17 18:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm seeing an arm64 build failure with -rc1 and GCC trunk, although I
believe that the new compiler behaviour at the heart of the problem
has the potential to affect other architectures and other pieces of
kernel code relying on dead-code elimination to remove deliberately
undefined functions.
The failure looks like:
| drivers/built-in.o: In function `armada_3700_add_composite_clk':
|
| linux/drivers/clk/mvebu/armada-37xx-periph.c:351:
| undefined reference to `____ilog2_NaN'
|
| linux/drivers/clk/mvebu/armada-37xx-periph.c:351:(.text+0xc72e0):
| relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
| `____ilog2_NaN'
|
| make: *** [vmlinux] Error 1
and if we look at the source for armada_3700_add_composite_clk, we see
that this is caused by:
int table_size = 0;
rate->reg = reg + (u64)rate->reg;
for (clkt = rate->table; clkt->div; clkt++)
table_size++;
rate->width = order_base_2(table_size);
order_base_2 calls ilog2, which has the ____ilog2_NaN call:
#define ilog2(n) \
( \
__builtin_constant_p(n) ? ( \
(n) < 1 ? ____ilog2_NaN() : \
This is because we're in a curious case where GCC has emitted a
special-cased version of armada_3700_add_composite_clk, with table_size
effectively constant-folded as 0. Whilst we shouldn't see this in a
non-buggy kernel (hence the deliberate call to the undefined function
____ilog2_NaN), it means that the final link fails because we have a
____ilog2_NaN in the code, with a runtime check on table_size.
In other words, __builtin_constant_p appears to be weaker than we've
been assuming. Talking to the compiler guys here, this is due to the
"jump-threading" optimisation pass, so the patch below disables that.
A simpler example is:
int foo();
int bar();
int count(int *argc)
{
int table_size = 0;
for (; *argc; argc++)
table_size++;
if (__builtin_constant_p(table_size))
return table_size == 0 ? foo() : bar();
return bar();
}
which compiles to:
count:
ldr w0, [x0]
cbz w0, .L4
b bar
.p2align 3
.L4:
b foo
and, with the "optimisation" disabled:
count:
b bar
Thoughts? It feels awfully fragile disabling passes like this, but with
GCC transforming the code like this, I can't immediately think of a way
to preserve the intended behaviour of the code.
Will
--->8
diff --git a/Makefile b/Makefile
index 512e47a53e9a..750873d6d11e 100644
--- a/Makefile
+++ b/Makefile
@@ -641,6 +641,11 @@ endif
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
+# Stop gcc from converting switches into a form that defeats dead code
+# elimination and can subsequently lead to calls to intentionally
+# undefined functions appearing in the final link.
+KBUILD_CFLAGS += $(call cc-option,--param=max-fsm-thread-path-insns=1)
+
include scripts/Makefile.gcc-plugins
ifdef CONFIG_READABLE_ASM
^ permalink raw reply related
* [PATCH] arm64: sysreg: Fix use of XZR in write_sysreg_s
From: Mark Rutland @ 2016-10-17 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476724859-18818-1-git-send-email-will.deacon@arm.com>
On Mon, Oct 17, 2016 at 06:20:59PM +0100, Will Deacon wrote:
> Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
> {read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
> to system registers that are not supported by binutils.
>
> Unfortunately, this was implemented with the wrong template (%0 vs %x0),
> so in the case that we are writing a constant 0, we will generate
> invalid instruction syntax and bail with a cryptic assembler error:
>
> | Error: constant expression required
>
> This patch fixes the template.
>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Whoops; I should've spotted that in review. FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
> arch/arm64/include/asm/sysreg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index e8d46e8e6079..6c80b3699cb8 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -286,7 +286,7 @@ asm(
>
> #define write_sysreg_s(v, r) do { \
> u64 __val = (u64)v; \
> - asm volatile("msr_s " __stringify(r) ", %0" : : "rZ" (__val)); \
> + asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
> } while (0)
>
> static inline void config_sctlr_el1(u32 clear, u32 set)
> --
> 2.1.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* 4.7.6->4.8.1 Possible regression
From: Russell King - ARM Linux @ 2016-10-17 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476722858.483756177@f140.i.mail.ru>
On Mon, Oct 17, 2016 at 07:47:38PM +0300, Alexander Shiyan wrote:
> Hello.
>
> After a kernel update from 4.7.6 to 4.8.1, the bug appear once kernel run "init".
Please try this patch, thanks:
diff --git a/arch/arm/mm/abort-lv4t.S b/arch/arm/mm/abort-lv4t.S
index 6d8e8e3365d1..e81d09f1887d 100644
--- a/arch/arm/mm/abort-lv4t.S
+++ b/arch/arm/mm/abort-lv4t.S
@@ -48,7 +48,10 @@ ENTRY(v4t_late_abort)
/* c */ b do_DataAbort @ ldc rd, [rn], #m @ Same as ldr rd, [rn], #m
/* d */ b do_DataAbort @ ldc rd, [rn, #m]
/* e */ b .data_unknown
-/* f */
+/* f */ b .data_unknown
+
+.data_unknown_r9:
+ ldr r9, [sp], #4
.data_unknown: @ Part of jumptable
mov r0, r4
mov r1, r8
@@ -57,6 +60,7 @@ ENTRY(v4t_late_abort)
.data_arm_ldmstm:
tst r8, #1 << 21 @ check writeback bit
beq do_DataAbort @ no writeback -> no fixup
+ str r9, [sp, #-4]!
mov r7, #0x11
orr r7, r7, #0x1100
and r6, r8, r7
@@ -75,12 +79,14 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6, lsl #2 @ Undo increment
addeq r7, r7, r6, lsl #2 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrhpre:
tst r8, #1 << 21 @ Check writeback bit
beq do_DataAbort @ No writeback -> no fixup
.data_arm_lateldrhpost:
+ str r9, [sp, #-4]!
and r9, r8, #0x00f @ get Rm / low nibble of immediate value
tst r8, #1 << 22 @ if (immediate offset)
andne r6, r8, #0xf00 @ { immediate high nibble
@@ -93,6 +99,7 @@ ENTRY(v4t_late_abort)
subne r7, r7, r6 @ Undo incrmenet
addeq r7, r7, r6 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrpreconst:
@@ -101,12 +108,14 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostconst:
movs r6, r8, lsl #20 @ Get offset
beq do_DataAbort @ zero -> no fixup
+ str r9, [sp, #-4]!
and r9, r8, #15 << 16 @ Extract 'n' from instruction
ldr r7, [r2, r9, lsr #14] @ Get register 'Rn'
tst r8, #1 << 23 @ Check U bit
subne r7, r7, r6, lsr #20 @ Undo increment
addeq r7, r7, r6, lsr #20 @ Undo decrement
str r7, [r2, r9, lsr #14] @ Put register 'Rn'
+ ldr r9, [sp], #4
b do_DataAbort
.data_arm_lateldrprereg:
@@ -115,6 +124,7 @@ ENTRY(v4t_late_abort)
.data_arm_lateldrpostreg:
and r7, r8, #15 @ Extract 'm' from instruction
ldr r6, [r2, r7, lsl #2] @ Get register 'Rm'
+ str r9, [sp, #-4]!
mov r9, r8, lsr #7 @ get shift count
ands r9, r9, #31
and r7, r8, #0x70 @ get shift type
@@ -126,33 +136,33 @@ ENTRY(v4t_late_abort)
b .data_arm_apply_r6_and_rn
b .data_arm_apply_r6_and_rn @ 1: LSL #0
nop
- b .data_unknown @ 2: MUL?
+ b .data_unknown_r9 @ 2: MUL?
nop
- b .data_unknown @ 3: MUL?
+ b .data_unknown_r9 @ 3: MUL?
nop
mov r6, r6, lsr r9 @ 4: LSR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, lsr #32 @ 5: LSR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ 6: MUL?
+ b .data_unknown_r9 @ 6: MUL?
nop
- b .data_unknown @ 7: MUL?
+ b .data_unknown_r9 @ 7: MUL?
nop
mov r6, r6, asr r9 @ 8: ASR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, asr #32 @ 9: ASR #32
b .data_arm_apply_r6_and_rn
- b .data_unknown @ A: MUL?
+ b .data_unknown_r9 @ A: MUL?
nop
- b .data_unknown @ B: MUL?
+ b .data_unknown_r9 @ B: MUL?
nop
mov r6, r6, ror r9 @ C: ROR #!0
b .data_arm_apply_r6_and_rn
mov r6, r6, rrx @ D: RRX
b .data_arm_apply_r6_and_rn
- b .data_unknown @ E: MUL?
+ b .data_unknown_r9 @ E: MUL?
nop
- b .data_unknown @ F: MUL?
+ b .data_unknown_r9 @ F: MUL?
.data_thumb_abort:
ldrh r8, [r4] @ read instruction
@@ -190,6 +200,7 @@ ENTRY(v4t_late_abort)
.data_thumb_pushpop:
tst r8, #1 << 10
beq .data_unknown
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8) + R bit
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -204,9 +215,11 @@ ENTRY(v4t_late_abort)
addeq r7, r7, r6, lsl #2 @ increment SP if PUSH
subne r7, r7, r6, lsl #2 @ decrement SP if POP
str r7, [r2, #13 << 2]
+ ldr r9, [sp], #4
b do_DataAbort
.data_thumb_ldmstm:
+ str r9, [sp, #-4]!
and r6, r8, #0x55 @ hweight8(r8)
and r9, r8, #0xaa
add r6, r6, r9, lsr #1
@@ -219,4 +232,5 @@ ENTRY(v4t_late_abort)
and r6, r6, #15 @ number of regs to transfer
sub r7, r7, r6, lsl #2 @ always decrement
str r7, [r2, r9, lsr #6]
+ ldr r9, [sp], #4
b do_DataAbort
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently@9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply related
* [PATCH] ARM: dts: sunxi: Add cpu-supply for Olimex A20 EVB
From: Maxime Ripard @ 2016-10-17 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161015152340.43315-1-manu@bidouilliste.com>
Hi,
On Sat, Oct 15, 2016 at 05:23:40PM +0200, Emmanuel Vadot wrote:
> sun7i-a20-olimex-som-evb.dts doesn't contain cpu-supply needed for
> voltage-scaling with cpufreq-dt so define it.
> The default voltages are defined in sun7i-a20.dtsi.
>
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/3aebd1db/attachment-0001.sig>
^ permalink raw reply
* [PATCH 1/2] iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s
From: Lorenzo Pieralisi @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f9dfa5a4-f42a-265f-ab84-7599f2de37ed@arm.com>
On Mon, Oct 17, 2016 at 03:19:46PM +0100, Robin Murphy wrote:
> Hi Lorenzo,
>
> On 17/10/16 14:21, Lorenzo Pieralisi wrote:
> > On Mon, Oct 17, 2016 at 12:06:20PM +0100, Robin Murphy wrote:
> >> We now delay installing our per-bus iommu_ops until we know an SMMU has
> >> successfully probed, as they don't serve much purpose beforehand, and
> >> doing so also avoids fights between multiple IOMMU drivers in a single
> >> kernel. However, the upshot of passing the return value of bus_set_iommu()
> >> back from our probe function is that if there happens to be more than
> >> one SMMUv3 device in a system, the second and subsequent probes will
> >> wind up returning -EBUSY to the driver core and getting torn down again.
> >>
> >> There are essentially 3 cases in which bus_set_iommu() returns nonzero:
> >> 1. The bus already has iommu_ops installed
> >> 2. One of the add_device callbacks from the initial notifier failed
> >> 3. Allocating or installing the notifier itself failed
> >>
> >> The first two are down to devices other than the SMMU in question, so
> >> shouldn't abort an otherwise-successful SMMU probe, whilst the third is
> >> indicative of the kind of catastrophic system failure which isn't going
> >> to get much further anyway. Consequently, there is little harm in
> >> ignoring the return value either way.
> >>
> >> CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/arm-smmu-v3.c | 11 ++++-------
> >> 1 file changed, 4 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> >> index 15c01c3cd540..74fbef384deb 100644
> >> --- a/drivers/iommu/arm-smmu-v3.c
> >> +++ b/drivers/iommu/arm-smmu-v3.c
> >> @@ -2637,16 +2637,13 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev)
> >> of_iommu_set_ops(dev->of_node, &arm_smmu_ops);
> >> #ifdef CONFIG_PCI
> >> pci_request_acs();
> >> - ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
> >> #endif
> >> #ifdef CONFIG_ARM_AMBA
> >> - ret = bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> - if (ret)
> >> - return ret;
> >> + bus_set_iommu(&amba_bustype, &arm_smmu_ops);
> >> #endif
> >> - return bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + bus_set_iommu(&platform_bus_type, &arm_smmu_ops);
> >> + return 0;
> >
> > Nit: I do not see why you would not take the same approach as
> > the ARM SMMUv1/v2, namely checking if ops are already set and
> > skip the call if that's the case.
>
> Well, I'd say it really goes the other way around - since the very first
> thing bus_set_iommu() does is check if ops are present, and return if
> so, and the v2 driver already doesn't care about that return value,
> there's not really any need for it to duplicate the check either. I
> didn't change it at the time to avoid cluttering the gigantic rework any
> further, but I could spin a cleanup patch if you like.
No worries, it was to understand if there was a reason to keep
the code different and after another look I agree with what
you are saying (by checking if ops are present you could eg
avoid calling pci_request_acs() every probe but that's a detail).
Thanks for fixing it !
Lorenzo
> > Anyway:
> >
> > Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>
> Thanks!
>
> Robin.
>
^ permalink raw reply
* [PATCH v8 1/2] ARM: dts: Add TOPEET itop core board SCP package version
From: ayaka @ 2016-10-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017162759.GA25818@kozik-lap>
On 10/18/2016 12:27 AM, Krzysztof Kozlowski wrote:
> On Mon, Sep 19, 2016 at 11:48:22PM +0800, Randy Li wrote:
>> The TOPEET itop is a samsung exnynos 4412 core board, which have
>> two package versions. This patch add the support for SCP version.
>>
>> Currently supported are USB3503A HSIC, USB OTG, eMMC, rtc and
>> PMIC. The future features are in the based board. Also MFC and
>> watchdog have been enabled.
>>
>> Signed-off-by: Randy Li <ayaka@soulik.info>
>> ---
>> arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++++++++++
>> 1 file changed, 501 insertions(+)
>> create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
> I wanted to apply it... but then I saw a bunch of checkpatch trivial issues.
> Really, after v8? The code must compile (v6 did not compile...), there
> should be no warnings from smatch, sparse and checkpatch (only the last
> one is applicable for DTS). Unless of course checkpatch would be
> wrong... but in this case it is correct. You did not follow coding
> style:
>
> WARNING: please, no spaces at the start of a line
> #134: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:109:
> + devfreq = <&bus_leftbus>;$
>
> ERROR: code indent should use tabs where possible
> #135: FILE: arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi:110:
> + status = "okay";$
Oh, it is a copy mistake, the copy operation makes the original tab
becomes spaces.
Should I send a new version to correct them?
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Regression: usb serial gadget on sama5d3 broken
From: Peter Rosin @ 2016-10-17 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <38ca0db7-9bc6-7258-b102-ea9fdeb9b03c@atmel.com>
On 2016-10-17 16:54, Nicolas Ferre wrote:
> Le 17/10/2016 ? 14:53, Peter Rosin a ?crit :
>> Hi!
>>
>> I'm suffering from a regression while using the usb gadget port on the
>> sama5d3 to get terminal access to the device in question (CONFIG_USB_G_SERIAL).
>>
>> I get this message when I try to connect:
>> udc: ep: Invalid setup request: 02.01 v0000 i0081 l0, halting endpoint...
>>
>> A bisect blames commit v4.7-rc1-21-gc32b5bcfa3c4 "ARM: dts: at91: Fix
>> USB endpoint nodes".
>>
>> And indeed, reverting that commit on top of v4.9-rc1 fixes things,
>> although that doesn't look like the best of fixes...
>>
>> BTW, the bisect was extremely painful since v4.7-rc1 seemed broken
>> somewhere in the overlayfs area. I hope I will never ever need to bisect
>> in the v4.6..v4.7 area again. This was the second time, the first time
>> I was chasing a gpio interrupt bug, but I never found out what was wrong
>> and stopped looking when v4.9-rc1 turned out to be ok even though v4.8
>> was bad, it was just too painful to look for things that already seemed
>> fixed.
>
> I guess that you are referring to the regression listed here:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1239220.html
>
> The patch is available and will hopefully land in an official kernel
> soon (4.8.1) as said by Felipe and Greg.
>
> Sorry for the inconvenience. Best regards,
Ok, I tried "usb: gadget: udc: atmel: fix endpoint name" and it fixes
things for me too. But shouldn't the memory for the now dynamic name be
allocated with devm_kasprintf instead of that plain kasprint? If you
are pedantic...
Cheers,
Peter
^ permalink raw reply
* [PATCH 1/2] i2c: bcm-iproc: constify i2c_adapter_quirks structures
From: Ray Jui @ 2016-10-17 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476552722-12352-2-git-send-email-Julia.Lawall@lip6.fr>
Hi Julia,
On 10/15/2016 10:32 AM, Julia Lawall wrote:
> Check for i2c_adapter_quirks structures that are only stored in the
> quirks field of an i2c_adapter structure. This field is declared
> const, so i2c_adapter_quirks structures that have this property can be
> declared as const also.
>
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct i2c_adapter_quirks i at p = { ... };
>
> @ok@
> identifier r.i;
> struct i2c_adapter e;
> position p;
> @@
> e.quirks = &i at p;
>
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct i2c_adapter_quirks e;
> @@
> e at i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
> struct i2c_adapter_quirks i = { ... };
> // </smpl>
>
> The effect on the layout of the .o file is shown by the following
> output of the size command, first before then after the
> transformation:
>
> text data bss dec hex filename
> 3458 744 8 4210 1072 drivers/i2c/busses/i2c-bcm-iproc.o
> 3490 720 8 4218 107a drivers/i2c/busses/i2c-bcm-iproc.o
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> drivers/i2c/busses/i2c-bcm-iproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
> index 326b3db..318df55 100644
> --- a/drivers/i2c/busses/i2c-bcm-iproc.c
> +++ b/drivers/i2c/busses/i2c-bcm-iproc.c
> @@ -395,7 +395,7 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
> .functionality = bcm_iproc_i2c_functionality,
> };
>
> -static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> +static const struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
> /* need to reserve one byte in the FIFO for the slave address */
> .max_read_len = M_TX_RX_FIFO_SIZE - 1,
> };
>
Change looks good. Thanks.
Acked-by: Ray Jui <ray.jui@broadcom.com>
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Sudeep Holla @ 2016-10-17 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923140303.GA26672@red-moon>
On 23/09/16 15:03, Lorenzo Pieralisi wrote:
> On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
>> Current vexpress smp init code detects whether to override the
>> default smp ops with MCPM smp ops by matching the "cci-400"
>> compatible string, in that MCPM requires control over CCI ports
>> to manage low-power states entry/exit.
>>
>> The "cci-400" compatible string check is a necessary but not
>> sufficient condition for MCPM to work, because the cci-400
>> can be made visible to the kernel, but firmware can nonetheless
>> disable non-secure CCI ports control, while still allowing PMU
>> access; if booted in non-secure world, the kernel would still
>> blindly override smp operations with MCPM operations, resulting
>> in kernel faults when the CCI ports programming interface is
>> accessed from non-secure world.
>>
>> This means that the "cci-400" compatible string check would
>> result in a false positive in systems that eg boot in HYP mode,
>> where CCI ports non-secure access is explicitly not allowed,
>> and it is reported in the respective device tree nodes with
>> CCI ports marked as disabled.
>>
>> Refactor the smp operations initialization to make sure that
>> the kernel is actually allowed to take control over CCI ports
>> (by enabling MCPM smp operations) before overriding default
>> vexpress smp operations.
>>
>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> ---
>> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
>> 1 file changed, 24 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
>> index 8b8d072..6cfd782 100644
>> --- a/arch/arm/mach-vexpress/platsmp.c
>> +++ b/arch/arm/mach-vexpress/platsmp.c
>> @@ -26,17 +26,34 @@
>> bool __init vexpress_smp_init_ops(void)
>> {
>> #ifdef CONFIG_MCPM
>> + int cpu;
>> + struct device_node *cpu_node, *cci_node;
>> +
>> /*
>> - * The best way to detect a multi-cluster configuration at the moment
>> - * is to look for the presence of a CCI in the system.
>> + * The best way to detect a multi-cluster configuration
>> + * is to detect if the kernel can take over CCI ports
>> + * control. Loop over possible CPUs and check if CCI
>> + * port control is available.
>> * Override the default vexpress_smp_ops if so.
>> */
>> - struct device_node *node;
>> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
>> - if (node && of_device_is_available(node)) {
>> - mcpm_smp_set_ops();
>> - return true;
>> + for_each_possible_cpu(cpu) {
>> + bool available;
>> +
>> + cpu_node = of_get_cpu_node(cpu, NULL);
>> + if (WARN(!cpu_node, "Missing cpu device node!"))
>> + return false;
>> +
>> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
>> + available = cci_node && of_device_is_available(cci_node);
>> + of_node_put(cci_node);
>> + of_node_put(cpu_node);
>> +
>> + if (!available)
>> + return false;
>> }
>> +
>> + mcpm_smp_set_ops();
>> + return true;
>> #endif
>> return false;
>
> For the records, while moving the code around I missed I was ending
> up with this idiotic double return, I have already reworked the patch
> and will squash changes in the final version if we agree on the bulk of
> the code.
>
I applied both patches to [1] with the fix for the above issue. Let me
know if that's fine. I have tested both hyp mode boot and SVC mode +
MCPM boot with latest u-boot by just fliping a bit in the firmware
(board.txt) without recompiling the kernel.
--
Regards,
Sudeep
[1] git.kernel.org/sudeep.holla/linux/h/vexpress/for-next
^ permalink raw reply
* [PATCH V3 RFT 3/5] ARM64: dts: bcm283x: Use dtsi for USB host mode
From: Eric Anholt @ 2016-10-17 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1471792204-21908-4-git-send-email-stefan.wahren@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> In case dr_mode isn't passed via DT, the dwc2 driver defaults
> to OTG mode. But the Raspberry Pi 3 is designed only for host mode.
> So fix this issue by linking to the dtsi file which set the dr_mode
> to host.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Applied Gerd's Tested-by and merged to bcm2835-dt-64-next.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/1eb7a5d5/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: sysreg: Fix use of XZR in write_sysreg_s
From: Will Deacon @ 2016-10-17 17:20 UTC (permalink / raw)
To: linux-arm-kernel
Commit 8a71f0c656e0 ("arm64: sysreg: replace open-coded mrs_s/msr_s with
{read,write}_sysreg_s") introduced a write_sysreg_s macro for writing
to system registers that are not supported by binutils.
Unfortunately, this was implemented with the wrong template (%0 vs %x0),
so in the case that we are writing a constant 0, we will generate
invalid instruction syntax and bail with a cryptic assembler error:
| Error: constant expression required
This patch fixes the template.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/sysreg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index e8d46e8e6079..6c80b3699cb8 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -286,7 +286,7 @@ asm(
#define write_sysreg_s(v, r) do { \
u64 __val = (u64)v; \
- asm volatile("msr_s " __stringify(r) ", %0" : : "rZ" (__val)); \
+ asm volatile("msr_s " __stringify(r) ", %x0" : : "rZ" (__val)); \
} while (0)
static inline void config_sctlr_el1(u32 clear, u32 set)
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/7] ARM: dts: bcm283x: Define standard pinctrl groups in the gpio node.
From: Eric Anholt @ 2016-10-17 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474274603-24215-3-git-send-email-kraxel@redhat.com>
Gerd Hoffmann <kraxel@redhat.com> writes:
> From: Eric Anholt <eric@anholt.net>
>
> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
> function selects do for the pins, and there are a bunch of obvious
> groupings to be made. With these created, we'll be able to replace
> bcm2835-rpi.dtsi's main "set all of these pins to alt0" with
> references to specific groups we want enabled.
>
> Also add pinctrl groups for emmc and sdhost.
>
> Based on patches by Eric Anholt <eric@anholt.net>
I amended this line to "Based on patches by Eric Anholt, with fixups by
Gerd Hoffmann." to explain why it had me as author but you in signoff.
I had to resolve some conflicts on the way in because apparently you had
built this against a tree with 14 and 15 already dropped from alt0. I
think those resolutions were sufficiently mechanical that it didn't
merit a respin.
Merged the series to bcm2835-dt-next. Thanks for getting this done!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161017/8fe3d040/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox