date:20201118

From: Colin Ian King 

The call to pc_delete_flow can kfree the iter object, so the following
dev_err message that accesses iter->entry can accessmemory that has
just been kfree'd.  Fix this by adding a temporary variable 'entry'
that has a copy of iter->entry and also use this when indexing into
the array mcam->entry2target_pffunc[]. Also print the unsigned value
using the %u format specifier rather than %d.

Addresses-Coverity: ("Read from pointer after free")
Fixes: 55307fcb9258 ("octeontx2-af: Add mbox messages to install and delete 
MCAM rules")
Signed-off-by: Colin Ian King 
---
 drivers/infiniband/hw/mlx5/mem.c   | 2 +-
 drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c | 8 +---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c 
b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
index 4ddfdff33a61..14832b66d1fe 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
+++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc_fs.c
@@ -1218,11 +1218,13 @@ int rvu_mbox_handler_npc_delete_flow(struct rvu *rvu,
mutex_unlock(&mcam->lock);
 
list_for_each_entry_safe(iter, tmp, &del_list, list) {
+   u16 entry = iter->entry;
+
/* clear the mcam entry target pcifunc */
-   mcam->entry2target_pffunc[iter->entry] = 0x0;
+   mcam->entry2target_pffunc[entry] = 0x0;
if (npc_delete_flow(rvu, iter, pcifunc))
-   dev_err(rvu->dev, "rule deletion failed for entry:%d",
-   iter->entry);
+   dev_err(rvu->dev, "rule deletion failed for entry:%u",
+   entry);
}
 
return 0;
-- 
2.28.0

[PATCH 5/6] Drivers: hv: vmbus: Resolve race condition in vmbus_onoffer_rescind()

An erroneous or malicious host could send multiple rescind messages for
a same channel.  In vmbus_onoffer_rescind(), the guest maps the channel
ID to obtain a pointer to the channel object and it eventually releases
such object and associated data.  The host could time rescind messages
and lead to an use-after-free.  Add a new flag to the channel structure
to make sure that only one instance of vmbus_onoffer_rescind() can get
the reference to the channel object.

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/channel_mgmt.c | 12 
 include/linux/hyperv.h|  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 4072fd1f22146..68950a1e4b638 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -1063,6 +1063,18 @@ static void vmbus_onoffer_rescind(struct 
vmbus_channel_message_header *hdr)
 
mutex_lock(&vmbus_connection.channel_mutex);
channel = relid2channel(rescind->child_relid);
+   if (channel != NULL) {
+   /*
+* Guarantee that no other instance of vmbus_onoffer_rescind()
+* has got a reference to the channel object.  Synchronize on
+* &vmbus_connection.channel_mutex.
+*/
+   if (channel->rescind_ref) {
+   mutex_unlock(&vmbus_connection.channel_mutex);
+   return;
+   }
+   channel->rescind_ref = true;
+   }
mutex_unlock(&vmbus_connection.channel_mutex);
 
if (channel == NULL) {
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 2ea967bc17adf..f0d48a368f131 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -809,6 +809,7 @@ struct vmbus_channel {
u8 monitor_bit;
 
bool rescind; /* got rescind msg */
+   bool rescind_ref; /* got rescind msg, got channel reference */
struct completion rescind_event;
 
u32 ringbuffer_gpadlhandle;
-- 
2.25.1

[PATCH 3/6] Drivers: hv: vmbus: Avoid double fetch of payload_size in vmbus_on_msg_dpc()

vmbus_on_msg_dpc() double fetches from payload_size.  The double fetch
can lead to a buffer overflow when (mem)copying the hv_message object.
Avoid the double fetch by saving the value of payload_size into a local
variable.

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/vmbus_drv.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 82b23baa446d7..0e39f1d6182e9 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1056,6 +1056,7 @@ void vmbus_on_msg_dpc(unsigned long data)
void *page_addr = hv_cpu->synic_message_page;
struct hv_message *msg = (struct hv_message *)page_addr +
  VMBUS_MESSAGE_SINT;
+   __u8 payload_size = msg->header.payload_size;
struct vmbus_channel_message_header *hdr;
enum vmbus_channel_message_type msgtype;
const struct vmbus_channel_message_table_entry *entry;
@@ -1089,9 +1090,8 @@ void vmbus_on_msg_dpc(unsigned long data)
goto msg_handled;
}
 
-   if (msg->header.payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT) {
-   WARN_ONCE(1, "payload size is too large (%d)\n",
- msg->header.payload_size);
+   if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT) {
+   WARN_ONCE(1, "payload size is too large (%d)\n", payload_size);
goto msg_handled;
}
 
@@ -1100,21 +1100,18 @@ void vmbus_on_msg_dpc(unsigned long data)
if (!entry->message_handler)
goto msg_handled;
 
-   if (msg->header.payload_size < entry->min_payload_len) {
-   WARN_ONCE(1, "message too short: msgtype=%d len=%d\n",
- msgtype, msg->header.payload_size);
+   if (payload_size < entry->min_payload_len) {
+   WARN_ONCE(1, "message too short: msgtype=%d len=%d\n", msgtype, 
payload_size);
goto msg_handled;
}
 
if (entry->handler_type == VMHT_BLOCKING) {
-   ctx = kmalloc(sizeof(*ctx) + msg->header.payload_size,
- GFP_ATOMIC);
+   ctx = kmalloc(sizeof(*ctx) + payload_size, GFP_ATOMIC);
if (ctx == NULL)
return;
 
INIT_WORK(&ctx->work, vmbus_onmessage_work);
-   memcpy(&ctx->msg, msg, sizeof(msg->header) +
-  msg->header.payload_size);
+   memcpy(&ctx->msg, msg, sizeof(msg->header) + payload_size);
 
/*
 * The host can generate a rescind message while we
-- 
2.25.1

[PATCH 6/6] Drivers: hv: vmbus: Do not allow overwriting vmbus_connection.channels[]

Currently, vmbus_onoffer() and vmbus_process_offer() are not validating
whether a given entry in the vmbus_connection.channels[] array is empty
before filling the entry with a call of vmbus_channel_map_relid().  An
erroneous or malicious host could rely on this to leak channel objects.
Do not allow overwriting an entry vmbus_connection.channels[].

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/channel_mgmt.c | 30 ++
 drivers/hv/hyperv_vmbus.h |  2 +-
 2 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 68950a1e4b638..841c0d4e101bd 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -354,10 +354,12 @@ static void free_channel(struct vmbus_channel *channel)
kobject_put(&channel->kobj);
 }
 
-void vmbus_channel_map_relid(struct vmbus_channel *channel)
+int vmbus_channel_map_relid(struct vmbus_channel *channel)
 {
-   if (WARN_ON(channel->offermsg.child_relid >= MAX_CHANNEL_RELIDS))
-   return;
+   u32 relid = channel->offermsg.child_relid;
+
+   if (WARN_ON(relid >= MAX_CHANNEL_RELIDS || 
vmbus_connection.channels[relid] != NULL))
+   return -EINVAL;
/*
 * The mapping of the channel's relid is visible from the CPUs that
 * execute vmbus_chan_sched() by the time that vmbus_chan_sched() will
@@ -383,18 +385,17 @@ void vmbus_channel_map_relid(struct vmbus_channel 
*channel)
 *  of the VMBus driver and vmbus_chan_sched() can not run before
 *  vmbus_bus_resume() has completed execution (cf. resume_noirq).
 */
-   smp_store_mb(
-   vmbus_connection.channels[channel->offermsg.child_relid],
-   channel);
+   smp_store_mb(vmbus_connection.channels[relid], channel);
+   return 0;
 }
 
 void vmbus_channel_unmap_relid(struct vmbus_channel *channel)
 {
-   if (WARN_ON(channel->offermsg.child_relid >= MAX_CHANNEL_RELIDS))
+   u32 relid = channel->offermsg.child_relid;
+
+   if (WARN_ON(relid >= MAX_CHANNEL_RELIDS))
return;
-   WRITE_ONCE(
-   vmbus_connection.channels[channel->offermsg.child_relid],
-   NULL);
+   WRITE_ONCE(vmbus_connection.channels[relid], NULL);
 }
 
 static void vmbus_release_relid(u32 relid)
@@ -601,6 +602,12 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
 */
atomic_dec(&vmbus_connection.offer_in_progress);
 
+   if (vmbus_channel_map_relid(newchannel)) {
+   mutex_unlock(&vmbus_connection.channel_mutex);
+   kfree(newchannel);
+   return;
+   }
+
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
if (guid_equal(&channel->offermsg.offer.if_type,
   &newchannel->offermsg.offer.if_type) &&
@@ -619,6 +626,7 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
 * Check to see if this is a valid sub-channel.
 */
if (newchannel->offermsg.offer.sub_channel_index == 0) {
+   vmbus_channel_unmap_relid(newchannel);
mutex_unlock(&vmbus_connection.channel_mutex);
/*
 * Don't call free_channel(), because newchannel->kobj
@@ -635,8 +643,6 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
list_add_tail(&newchannel->sc_list, &channel->sc_list);
}
 
-   vmbus_channel_map_relid(newchannel);
-
mutex_unlock(&vmbus_connection.channel_mutex);
cpus_read_unlock();
 
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index e2064bf2b557d..89d7b95b3bdad 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -338,7 +338,7 @@ int vmbus_add_channel_kobj(struct hv_device *device_obj,
 
 void vmbus_remove_channel_attr_group(struct vmbus_channel *channel);
 
-void vmbus_channel_map_relid(struct vmbus_channel *channel);
+int vmbus_channel_map_relid(struct vmbus_channel *channel);
 void vmbus_channel_unmap_relid(struct vmbus_channel *channel);
 
 struct vmbus_channel *relid2channel(u32 relid);
-- 
2.25.1

[PATCH 1/6] Drivers: hv: vmbus: Initialize memory to be sent to the host

__vmbus_open() and vmbus_teardown_gpadl() do not inizialite the memory
for the vmbus_channel_open_channel and the vmbus_channel_gpadl_teardown
objects they allocate respectively.  These objects contain padding bytes
and fields that are left uninitialized and that are later sent to the
host, potentially leaking guest data.  Zero initialize such fields to
avoid leaking sensitive information to the host.

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/channel.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 0d63862d65518..9aa789e5f22bb 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -621,7 +621,7 @@ static int __vmbus_open(struct vmbus_channel *newchannel,
goto error_clean_ring;
 
/* Create and init the channel open message */
-   open_info = kmalloc(sizeof(*open_info) +
+   open_info = kzalloc(sizeof(*open_info) +
   sizeof(struct vmbus_channel_open_channel),
   GFP_KERNEL);
if (!open_info) {
@@ -748,7 +748,7 @@ int vmbus_teardown_gpadl(struct vmbus_channel *channel, u32 
gpadl_handle)
unsigned long flags;
int ret;
 
-   info = kmalloc(sizeof(*info) +
+   info = kzalloc(sizeof(*info) +
   sizeof(struct vmbus_channel_gpadl_teardown), GFP_KERNEL);
if (!info)
return -ENOMEM;
-- 
2.25.1

[PATCH 4/6] Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind()

When channel->device_obj is non-NULL, vmbus_onoffer_rescind() could
invoke put_device(), that will eventually release the device and free
the channel object (cf. vmbus_device_release()).  However, a pointer
to the object is dereferenced again later to load the primary_channel.
The use-after-free can be avoided by noticing that this load/check is
redundant if device_obk is non-NULL: primary_channel must be NULL if
device_obj is non-NULL, cf. vmbus_add_channel_work().

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/channel_mgmt.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 5bc5eef5da159..4072fd1f22146 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -1116,8 +1116,7 @@ static void vmbus_onoffer_rescind(struct 
vmbus_channel_message_header *hdr)
vmbus_device_unregister(channel->device_obj);
put_device(dev);
}
-   }
-   if (channel->primary_channel != NULL) {
+   } else if (channel->primary_channel != NULL) {
/*
 * Sub-channel is being rescinded. Following is the channel
 * close sequence when initiated from the driveri (refer to
-- 
2.25.1

[PATCH 2/6] Drivers: hv: vmbus: Avoid double fetch of msgtype in vmbus_on_msg_dpc()

vmbus_on_msg_dpc() double fetches from msgtype.  The double fetch can
lead to an out-of-bound access when accessing the channel_message_table
array.  In turn, the use of the out-of-bound entry could lead to code
execution primitive (entry->message_handler()).  Avoid the double fetch
by saving the value of msgtype into a local variable.

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
---
 drivers/hv/vmbus_drv.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 0a2711aa63a15..82b23baa446d7 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1057,6 +1057,7 @@ void vmbus_on_msg_dpc(unsigned long data)
struct hv_message *msg = (struct hv_message *)page_addr +
  VMBUS_MESSAGE_SINT;
struct vmbus_channel_message_header *hdr;
+   enum vmbus_channel_message_type msgtype;
const struct vmbus_channel_message_table_entry *entry;
struct onmessage_work_context *ctx;
u32 message_type = msg->header.message_type;
@@ -1072,12 +1073,19 @@ void vmbus_on_msg_dpc(unsigned long data)
/* no msg */
return;
 
+   /*
+* The hv_message object is in memory shared with the host.  The host
+* could erroneously or maliciously modify such object.  Make sure to
+* validate its fields and avoid double fetches whenever feasible.
+*/
+
hdr = (struct vmbus_channel_message_header *)msg->u.payload;
+   msgtype = hdr->msgtype;
 
trace_vmbus_on_msg_dpc(hdr);
 
-   if (hdr->msgtype >= CHANNELMSG_COUNT) {
-   WARN_ONCE(1, "unknown msgtype=%d\n", hdr->msgtype);
+   if (msgtype >= CHANNELMSG_COUNT) {
+   WARN_ONCE(1, "unknown msgtype=%d\n", msgtype);
goto msg_handled;
}
 
@@ -1087,14 +1095,14 @@ void vmbus_on_msg_dpc(unsigned long data)
goto msg_handled;
}
 
-   entry = &channel_message_table[hdr->msgtype];
+   entry = &channel_message_table[msgtype];
 
if (!entry->message_handler)
goto msg_handled;
 
if (msg->header.payload_size < entry->min_payload_len) {
WARN_ONCE(1, "message too short: msgtype=%d len=%d\n",
- hdr->msgtype, msg->header.payload_size);
+ msgtype, msg->header.payload_size);
goto msg_handled;
}
 
@@ -1115,7 +1123,7 @@ void vmbus_on_msg_dpc(unsigned long data)
 * by offer_in_progress and by channel_mutex.  See also the
 * inline comments in vmbus_onoffer_rescind().
 */
-   switch (hdr->msgtype) {
+   switch (msgtype) {
case CHANNELMSG_RESCIND_CHANNELOFFER:
/*
 * If we are handling the rescind message;
-- 
2.25.1

[PATCH 0/6] Drivers: hv: vmbus: More VMBus-hardening changes

Hi all,

This set is a continuation of the work for hardening the VMBus drivers
against an erroneous or malicious host.  This is based on hyperv-next.

Thanks,
  Andrea

Andrea Parri (Microsoft) (6):
  Drivers: hv: vmbus: Initialize memory to be sent to the host
  Drivers: hv: vmbus: Avoid double fetch of msgtype in
vmbus_on_msg_dpc()
  Drivers: hv: vmbus: Avoid double fetch of payload_size in
vmbus_on_msg_dpc()
  Drivers: hv: vmbus: Avoid use-after-free in vmbus_onoffer_rescind()
  Drivers: hv: vmbus: Resolve race condition in vmbus_onoffer_rescind()
  Drivers: hv: vmbus: Do not allow overwriting
vmbus_connection.channels[]

 drivers/hv/channel.c  |  4 ++--
 drivers/hv/channel_mgmt.c | 45 +++
 drivers/hv/hyperv_vmbus.h |  2 +-
 drivers/hv/vmbus_drv.c| 33 
 include/linux/hyperv.h|  1 +
 5 files changed, 54 insertions(+), 31 deletions(-)

-- 
2.25.1

[PATCH v3] tracepoint: Do not fail unregistering a probe due to memory allocation

From: "Steven Rostedt (VMware)" 

The list of tracepoint callbacks is managed by an array that is protected
by RCU. To update this array, a new array is allocated, the updates are
copied over to the new array, and then the list of functions for the
tracepoint is switched over to the new array. After a completion of an RCU
grace period, the old array is freed.

This process happens for both adding a callback as well as removing one.
But on removing a callback, if the new array fails to be allocated, the
callback is not removed, and may be used after it is freed by the clients
of the tracepoint.

There's really no reason to fail if the allocation for a new array fails
when removing a function. Instead, the function can simply be replaced by a
stub function that could be cleaned up on the next modification of the
array. That is, instead of calling the function registered to the
tracepoint, it would call a stub function in its place.

Link: https://lore.kernel.org/r/20201115055256.65625-1-mmull...@mmlx.us
Link: https://lore.kernel.org/r/20201116175107.02db3...@gandalf.local.home
Link: https://lore.kernel.org/r/20201117211836.54aca...@oasis.local.home

Cc: Mathieu Desnoyers 
Cc: Ingo Molnar 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Dmitry Vyukov 
Cc: Martin KaFai Lau 
Cc: Song Liu 
Cc: Yonghong Song 
Cc: Andrii Nakryiko 
Cc: John Fastabend 
Cc: KP Singh 
Cc: netdev 
Cc: bpf 
Cc: Kees Cook 
Cc: Florian Weimer 
Fixes: 97e1c18e8d17b ("tracing: Kernel Tracepoints")
Reported-by: syzbot+83aa762ef23b6f0d1...@syzkaller.appspotmail.com
Reported-by: syzbot+d29e58bb557324e55...@syzkaller.appspotmail.com
Reported-by: Matt Mullins 
Signed-off-by: Steven Rostedt (VMware) 
---
Changes since v2:
   - Went back to using a stub function and not touching
  the fast path.
   - Removed adding __GFP_NOFAIL from the allocation of the removal.

 kernel/tracepoint.c | 80 -
 1 file changed, 64 insertions(+), 16 deletions(-)

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 3f659f855074..3e261482296c 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -53,6 +53,12 @@ struct tp_probes {
struct tracepoint_func probes[];
 };
 
+/* Called in removal of a func but failed to allocate a new tp_funcs */
+static void tp_stub_func(void)
+{
+   return;
+}
+
 static inline void *allocate_probes(int count)
 {
struct tp_probes *p  = kmalloc(struct_size(p, probes, count),
@@ -131,6 +137,7 @@ func_add(struct tracepoint_func **funcs, struct 
tracepoint_func *tp_func,
 {
struct tracepoint_func *old, *new;
int nr_probes = 0;
+   int stub_funcs = 0;
int pos = -1;
 
if (WARN_ON(!tp_func->func))
@@ -147,14 +154,34 @@ func_add(struct tracepoint_func **funcs, struct 
tracepoint_func *tp_func,
if (old[nr_probes].func == tp_func->func &&
old[nr_probes].data == tp_func->data)
return ERR_PTR(-EEXIST);
+   if (old[nr_probes].func == tp_stub_func)
+   stub_funcs++;
}
}
-   /* + 2 : one for new probe, one for NULL func */
-   new = allocate_probes(nr_probes + 2);
+   /* + 2 : one for new probe, one for NULL func - stub functions */
+   new = allocate_probes(nr_probes + 2 - stub_funcs);
if (new == NULL)
return ERR_PTR(-ENOMEM);
if (old) {
-   if (pos < 0) {
+   if (stub_funcs) {
+   /* Need to copy one at a time to remove stubs */
+   int probes = 0;
+
+   pos = -1;
+   for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
+   if (old[nr_probes].func == tp_stub_func)
+   continue;
+   if (pos < 0 && old[nr_probes].prio < prio)
+   pos = probes++;
+   new[probes++] = old[nr_probes];
+   }
+   nr_probes = probes;
+   if (pos < 0)
+   pos = probes;
+   else
+   nr_probes--; /* Account for insertion */
+
+   } else if (pos < 0) {
pos = nr_probes;
memcpy(new, old, nr_probes * sizeof(struct 
tracepoint_func));
} else {
@@ -188,8 +215,9 @@ static void *func_remove(struct tracepoint_func **funcs,
/* (N -> M), (N > 1, M >= 0) probes */
if (tp_func->func) {
for (nr_probes = 0; old[nr_probes].func; nr_probes++) {
-   if (old[nr_probes].func == tp_func->func &&
-old[nr_probes].data == tp_func->data)
+   if ((old[nr_probes].func == tp_func->func &&
+old[nr_pro

[PATCH] gpio: omap: handle deferred probe with dev_err_probe() for gpiochip_add_data()

The gpiochip_add_data() may return -EPROBE_DEFER which is not handled
properly by TI GPIO driver and causes unnecessary boot log messages.

Hence, add proper deferred probe handling with new dev_err_probe() API.

Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpio-omap.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index f7ceb2b11afc..41952bb818ad 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1049,11 +1049,8 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
irq->first = irq_base;
 
ret = gpiochip_add_data(&bank->chip, bank);
-   if (ret) {
-   dev_err(bank->chip.parent,
-   "Could not register gpio chip %d\n", ret);
-   return ret;
-   }
+   if (ret)
+   return dev_err_probe(bank->chip.parent, ret, "Could not 
register gpio chip\n");
 
ret = devm_request_irq(bank->chip.parent, bank->irq,
   omap_gpio_irq_handler,
-- 
2.17.1

Re: [RFC PATCH 15/27] of/fdt: Introduce early_init_dt_add_memory_hyp()

2020-11-18 Thread Quentin Perret

On Wednesday 18 Nov 2020 at 09:25:47 (+), Quentin Perret wrote:
> I'll have a go at the memblock stuff to see if I find a way to make it
> work from that angle.

OK, no luck with the memblock API, but I figured that I can actually
postpone the KVM memory reservation to a later point, after
unflatten_device_tree(), which lets me iterate over the memory nodes
directly rather than having the fdt driver do it for me.

The below seems to boot alright (though I'm not too familiar with
of_address_to_resource() so I may not be using right) and keeps the
whole thing in arch/arm64. Thoughts?

Thanks,
Quentin

---8<---
diff --git a/arch/arm64/kvm/hyp/reserved_mem.c 
b/arch/arm64/kvm/hyp/reserved_mem.c
index 7da8e2915c1c..cab5ad587a3a 100644
--- a/arch/arm64/kvm/hyp/reserved_mem.c
+++ b/arch/arm64/kvm/hyp/reserved_mem.c
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -16,7 +17,7 @@
 phys_addr_t hyp_mem_base;
 phys_addr_t hyp_mem_size;
 
-void __init early_init_dt_add_memory_hyp(u64 base, u64 size)
+static int __init add_hyp_memblock_region(struct resource *rsrc)
 {
struct hyp_memblock_region *reg;
 
@@ -24,12 +25,14 @@ void __init early_init_dt_add_memory_hyp(u64 base, u64 size)
kvm_nvhe_sym(hyp_memblock_nr) = -1;
 
if (kvm_nvhe_sym(hyp_memblock_nr) < 0)
-   return;
+   return -ENOMEM;
 
reg = kvm_nvhe_sym(hyp_memory);
-   reg[kvm_nvhe_sym(hyp_memblock_nr)].start = base;
-   reg[kvm_nvhe_sym(hyp_memblock_nr)].end = base + size;
+   reg[kvm_nvhe_sym(hyp_memblock_nr)].start = rsrc->start;
+   reg[kvm_nvhe_sym(hyp_memblock_nr)].end = rsrc->end;
kvm_nvhe_sym(hyp_memblock_nr)++;
+
+   return 0;
 }
 
 static int cmp_hyp_memblock(const void *p1, const void *p2)
@@ -52,7 +55,10 @@ void kvm_sort_memblock_regions(void)
 extern bool enable_protected_kvm;
 void __init reserve_kvm_hyp(void)
 {
+   struct device_node *np;
+   struct resource rsrc;
u64 nr_pages, prev;
+   int i;
 
if (!enable_protected_kvm)
return;
@@ -60,8 +66,14 @@ void __init reserve_kvm_hyp(void)
if (!is_hyp_mode_available() || is_kernel_in_hyp_mode())
return;
 
-   if (kvm_nvhe_sym(hyp_memblock_nr) <= 0)
-   return;
+   for_each_node_by_type(np, "memory") {
+   for (i = 0; !of_address_to_resource(np, i, &rsrc); i++) {
+   if (!add_hyp_memblock_region(&rsrc))
+   continue;
+   kvm_err("Failed to add hyp memblock\n");
+   return;
+   }
+   }
 
hyp_mem_size += num_possible_cpus() << PAGE_SHIFT;
hyp_mem_size += hyp_s1_pgtable_size();
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index f81da019b677..114f788a4da4 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -391,7 +391,6 @@ void __init arm64_memblock_init(void)
 
reserve_elfcorehdr();
 
-   reserve_kvm_hyp();
 
high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
 
@@ -423,6 +422,8 @@ void __init bootmem_init(void)
 
dma_pernuma_cma_reserve();
 
+   reserve_kvm_hyp();
+
/*
 * sparse_init() tries to allocate memory from memblock, so must be
 * done after the fixed reservations
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index af2b5a09c5b4..4602e467ca8b 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1099,10 +1099,6 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 #define MAX_MEMBLOCK_ADDR  ((phys_addr_t)~0)
 #endif
 
-void __init __weak early_init_dt_add_memory_hyp(u64 base, u64 size)
-{
-}
-
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
const u64 phys_offset = MIN_MEMBLOCK_ADDR;
@@ -1143,7 +1139,6 @@ void __init __weak early_init_dt_add_memory_arch(u64 
base, u64 size)
base = phys_offset;
}
memblock_add(base, size);
-   early_init_dt_add_memory_hyp(base, size);
 }
 
 int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)

[gustavoars-linux:testing/clang-ft/lib] BUILD SUCCESS 02ec42c445b349042b8361294a9ff72fc3193f18

2020-11-18 Thread kernel test robot

 randconfig-a006-20201118
i386 randconfig-a005-20201118
i386 randconfig-a002-20201118
i386 randconfig-a001-20201118
i386 randconfig-a003-20201118
i386 randconfig-a004-20201118
x86_64   randconfig-a005-20201118
x86_64   randconfig-a003-20201118
x86_64   randconfig-a004-20201118
x86_64   randconfig-a002-20201118
x86_64   randconfig-a006-20201118
x86_64   randconfig-a001-20201118
i386 randconfig-a012-20201118
i386 randconfig-a014-20201118
i386 randconfig-a016-20201118
i386 randconfig-a011-20201118
i386 randconfig-a013-20201118
i386 randconfig-a015-20201118
i386 randconfig-a012-20201117
i386 randconfig-a014-20201117
i386 randconfig-a011-20201117
i386 randconfig-a013-20201117
i386 randconfig-a016-20201117
i386 randconfig-a015-20201117
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a003-20201117
x86_64   randconfig-a005-20201117
x86_64   randconfig-a004-20201117
x86_64   randconfig-a002-20201117
x86_64   randconfig-a001-20201117
x86_64   randconfig-a006-20201117
x86_64   randconfig-a015-20201118
x86_64   randconfig-a014-20201118
x86_64   randconfig-a011-20201118
x86_64   randconfig-a013-20201118
x86_64   randconfig-a016-20201118
x86_64   randconfig-a012-20201118
x86_64   randconfig-a015-20201116
x86_64   randconfig-a011-20201116
x86_64   randconfig-a014-20201116
x86_64   randconfig-a013-20201116
x86_64   randconfig-a016-20201116
x86_64   randconfig-a012-20201116

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

2020-11-18 Thread Tetsuo Handa

The problem is that we can't know what exactly is consuming these resources.
My question is do you have a plan to make it possible to know what exactly is
consuming these resources.

On 2020/11/18 23:23, Peter Zijlstra wrote:
> On Wed, Nov 18, 2020 at 10:57:08PM +0900, Tetsuo Handa wrote:
>> Peter, do you have a plan to make this problem actionable?
> 
> I don't even know what the problem is.. nor do you. You can keep sending
> this bad paper-over-issues patch until you're blue in the face, I'll not
> take it for reasons I've explained before.
> 
> I've also previously said that the right way to go about this is to
> figure out what exactly is consuming these resources and then figure out
> how to cure _that_. Blindly increasing the number only enables bad
> actors to get away with being bad.
>

[PATCH] gpiolib: do not print err message for EPROBE_DEFER

The gpiochip may have dependencies from pinmux and so got deferred. Now it
will print error message every time -EPROBE_DEFER is returned which is
unnecessary:

"gpiochip_add_data_with_key: GPIOs 0..31 (gpio-0-31) failed to register, -517"

Hence, do suppress error message for -EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
 drivers/gpio/gpiolib.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 089ddcaa9bc6..fd2c503a6aab 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -771,9 +771,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void 
*data,
ida_free(&gpio_ida, gdev->id);
 err_free_gdev:
/* failures here can mean systems won't boot... */
-   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", __func__,
-  gdev->base, gdev->base + gdev->ngpio - 1,
-  gc->label ? : "generic", ret);
+   if (ret != -EPROBE_DEFER) {
+   pr_err("%s: GPIOs %d..%d (%s) failed to register, %d\n", 
__func__,
+  gdev->base, gdev->base + gdev->ngpio - 1,
+  gc->label ? : "generic", ret);
+   }
kfree(gdev);
return ret;
 }
-- 
2.17.1

Re: possible deadlock in _destroy_id

2020-11-18 Thread syzbot

syzbot has found a reproducer for the following issue on:

HEAD commit:20529233 Add linux-next specific files for 20201118
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16ce97be50
kernel config:  https://syzkaller.appspot.com/x/.config?x=2c4fb58b6526b3c1
dashboard link: https://syzkaller.appspot.com/bug?extid=1bc48bf7f78253f664a9
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10b5398150
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10e94c7e50

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1bc48bf7f78253f66...@syzkaller.appspotmail.com

wlan1 speed is unknown, defaulting to 1000
iwpm_register_pid: Unable to send a nlmsg (client = 2)
infiniband syz2: RDMA CMA: cma_listen_on_dev, error -98

WARNING: possible recursive locking detected
5.10.0-rc4-next-20201118-syzkaller #0 Not tainted

syz-executor872/8502 is trying to acquire lock:
8c684748 (lock#6){+.+.}-{3:3}, at: cma_release_dev 
drivers/infiniband/core/cma.c:476 [inline]
8c684748 (lock#6){+.+.}-{3:3}, at: _destroy_id+0x299/0xa00 
drivers/infiniband/core/cma.c:1852

but task is already holding lock:
8c684748 (lock#6){+.+.}-{3:3}, at: cma_add_one+0x55c/0xce0 
drivers/infiniband/core/cma.c:4902

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(lock#6);
  lock(lock#6);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

6 locks held by syz-executor872/8502:
 #0: 8fa76958 (&rdma_nl_types[idx].sem){.+.+}-{3:3}, at: 
rdma_nl_rcv_msg+0x15b/0x690 drivers/infiniband/core/netlink.c:164
 #1: 8c66c490 (link_ops_rwsem){}-{3:3}, at: 
nldev_newlink+0x261/0x540 drivers/infiniband/core/nldev.c:1545
 #2: 8c65bd90 (devices_rwsem){}-{3:3}, at: 
enable_device_and_get+0xfc/0x3c0 drivers/infiniband/core/device.c:1321
 #3: 8c65bc50 (clients_rwsem){}-{3:3}, at: 
enable_device_and_get+0x163/0x3c0 drivers/infiniband/core/device.c:1331
 #4: 888026f28598 (&device->client_data_rwsem){}-{3:3}, at: 
add_client_context+0x3d0/0x5e0 drivers/infiniband/core/device.c:710
 #5: 8c684748 (lock#6){+.+.}-{3:3}, at: cma_add_one+0x55c/0xce0 
drivers/infiniband/core/cma.c:4902

stack backtrace:
CPU: 1 PID: 8502 Comm: syz-executor872 Not tainted 
5.10.0-rc4-next-20201118-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:120
 print_deadlock_bug kernel/locking/lockdep.c:2759 [inline]
 check_deadlock kernel/locking/lockdep.c:2802 [inline]
 validate_chain kernel/locking/lockdep.c:3593 [inline]
 __lock_acquire.cold+0x115/0x39f kernel/locking/lockdep.c:4830
 lock_acquire kernel/locking/lockdep.c:5435 [inline]
 lock_acquire+0x2a3/0x8c0 kernel/locking/lockdep.c:5400
 __mutex_lock_common kernel/locking/mutex.c:956 [inline]
 __mutex_lock+0x134/0x1110 kernel/locking/mutex.c:1103
 cma_release_dev drivers/infiniband/core/cma.c:476 [inline]
 _destroy_id+0x299/0xa00 drivers/infiniband/core/cma.c:1852
 cma_listen_on_dev.cold+0x168/0x16d drivers/infiniband/core/cma.c:2535
 cma_add_one+0x667/0xce0 drivers/infiniband/core/cma.c:4905
 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:712
 enable_device_and_get+0x1d5/0x3c0 drivers/infiniband/core/device.c:1333
 ib_register_device drivers/infiniband/core/device.c:1408 [inline]
 ib_register_device+0x7a0/0xa30 drivers/infiniband/core/device.c:1367
 siw_device_register drivers/infiniband/sw/siw/siw_main.c:72 [inline]
 siw_newlink drivers/infiniband/sw/siw/siw_main.c:545 [inline]
 siw_newlink+0xddb/0x1340 drivers/infiniband/sw/siw/siw_main.c:522
 nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555
 rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195
 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
 rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:650 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:670
 sys_sendmsg+0x6e8/0x810 net/socket.c:2339
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2393
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2426
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440339
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff91ac9ae8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: fff

Re: linux-next: build warnings after merge of the v4l-dvb tree

2020-11-18 Thread Helen Koike

Hi Stephen,

On 11/18/20 2:32 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the v4l-dvb tree, today's linux-next build (htmldocs)
> produced these warnings:
> 
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must 
> precede a section header)
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must 
> precede a section header)
> 
> Introduced by commit
> 
>   df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer 
> format")
> 

Thanks for catching this, fix sent:


https://patchwork.linuxtv.org/project/linux-media/patch/20201118142400.3540109-1-helen.ko...@collabora.com/

Regards,
Helen

[PATCH] WIP! media: uvcvideo: Use dma_alloc_noncontiguos API

2020-11-18 Thread Ricardo Ribalda

On architectures where the is no coherent caching such as ARM use the
dma_alloc_noncontiguos API and handle manually the cache flushing using
dma_sync_single().

With this patch on the affected architectures we can measure up to 20x
performance improvement in uvc_video_copy_data_work().

Signed-off-by: Ricardo Ribalda 
---

This patch depends on dma_alloc_contiguous API1315351diffmboxseries

https://lore.kernel.org/patchwork/patch/1315351/#1535182

 drivers/media/usb/uvc/uvc_video.c | 69 +--
 drivers/media/usb/uvc/uvcvideo.h  |  1 +
 2 files changed, 58 insertions(+), 12 deletions(-)

diff --git a/drivers/media/usb/uvc/uvc_video.c 
b/drivers/media/usb/uvc/uvc_video.c
index ff624bb857d3..ef1b029b8576 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -1641,6 +1641,11 @@ static void uvc_video_encode_bulk(struct uvc_urb 
*uvc_urb,
urb->transfer_buffer_length = stream->urb_size - len;
 }
 
+static inline struct device *stream_to_dmadev(struct uvc_streaming *stream)
+{
+   return stream->dev->udev->bus->controller->parent;
+}
+
 static void uvc_video_complete(struct urb *urb)
 {
struct uvc_urb *uvc_urb = urb->context;
@@ -1693,6 +1698,11 @@ static void uvc_video_complete(struct urb *urb)
 * Process the URB headers, and optionally queue expensive memcpy tasks
 * to be deferred to a work queue.
 */
+   if (uvc_urb->pages)
+   dma_sync_single_for_cpu(stream_to_dmadev(stream),
+   urb->transfer_dma,
+   urb->transfer_buffer_length,
+   DMA_FROM_DEVICE);
stream->decode(uvc_urb, buf, buf_meta);
 
/* If no async work is needed, resubmit the URB immediately. */
@@ -1723,8 +1733,15 @@ static void uvc_free_urb_buffers(struct uvc_streaming 
*stream)
continue;
 
 #ifndef CONFIG_DMA_NONCOHERENT
-   usb_free_coherent(stream->dev->udev, stream->urb_size,
- uvc_urb->buffer, uvc_urb->dma);
+   if (uvc_urb->pages) {
+   vunmap(uvc_urb->buffer);
+   dma_free_noncontiguous(stream_to_dmadev(stream),
+  stream->urb_size,
+  uvc_urb->pages, uvc_urb->dma);
+   } else {
+   usb_free_coherent(stream->dev->udev, stream->urb_size,
+ uvc_urb->buffer, uvc_urb->dma);
+   }
 #else
kfree(uvc_urb->buffer);
 #endif
@@ -1734,6 +1751,42 @@ static void uvc_free_urb_buffers(struct uvc_streaming 
*stream)
stream->urb_size = 0;
 }
 
+#ifndef CONFIG_DMA_NONCOHERENT
+static bool uvc_alloc_urb_buffer(struct uvc_streaming *stream, struct uvc_urb 
*uvc_urb,
+gfp_t gfp_flags)
+{
+   struct device *dma_dev = dma_dev = stream_to_dmadev(stream);
+
+   if (!dma_can_alloc_noncontiguous(dma_dev)) {
+   uvc_urb->buffer = usb_alloc_coherent(stream->dev->udev, 
stream->urb_size,
+gfp_flags | __GFP_NOWARN, 
&uvc_urb->dma);
+   return uvc_urb->buffer != NULL;
+   }
+
+   uvc_urb->pages = dma_alloc_noncontiguous(dma_dev, stream->urb_size,
+&uvc_urb->dma, gfp_flags | 
__GFP_NOWARN, 0);
+   if (!uvc_urb->pages)
+   return false;
+
+   uvc_urb->buffer = vmap(uvc_urb->pages, PAGE_ALIGN(stream->urb_size) >> 
PAGE_SHIFT,
+  VM_DMA_COHERENT, PAGE_KERNEL);
+   if (!uvc_urb->buffer) {
+   dma_free_noncontiguous(dma_dev, stream->urb_size, 
uvc_urb->pages, uvc_urb->dma);
+   return false;
+   }
+
+   return true;
+}
+#else
+static bool uvc_alloc_urb_buffer(struct uvc_streaming *stream, struct uvc_urb 
*uvc_urb,
+gfp_t gfp_flags)
+{
+   uvc_urb->buffer = kmalloc(stream->urb_size, gfp_flags | __GFP_NOWARN);
+
+   return uvc_urb->buffer != NULL;
+}
+#endif
+
 /*
  * Allocate transfer buffers. This function can be called with buffers
  * already allocated when resuming from suspend, in which case it will
@@ -1764,19 +1817,11 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming 
*stream,
 
/* Retry allocations until one succeed. */
for (; npackets > 1; npackets /= 2) {
+   stream->urb_size = psize * npackets;
for (i = 0; i < UVC_URBS; ++i) {
struct uvc_urb *uvc_urb = &stream->uvc_urb[i];
 
-   stream->urb_size = psize * npackets;
-#ifndef CONFIG_DMA_NONCOHERENT
-   uvc_urb->buffer = usb_alloc_coherent(
-   stream->dev->udev, stream->urb_size,
-   gfp_flags | __GFP_NOWARN,

[PATCH] mdio_bus: suppress err message for reset gpio EPROBE_DEFER

The mdio_bus may have dependencies from GPIO controller and so got
deferred. Now it will print error message every time -EPROBE_DEFER is
returned from:
__mdiobus_register()
 |-devm_gpiod_get_optional()
without actually identifying error code.

"mdio_bus 4a101000.mdio: mii_bus 4a101000.mdio couldn't get reset GPIO"

Hence, suppress error message when devm_gpiod_get_optional() returning
-EPROBE_DEFER case.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/phy/mdio_bus.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 757e950fb745..54fc13043656 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -546,10 +546,11 @@ int __mdiobus_register(struct mii_bus *bus, struct module 
*owner)
/* de-assert bus level PHY GPIO reset */
gpiod = devm_gpiod_get_optional(&bus->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(gpiod)) {
-   dev_err(&bus->dev, "mii_bus %s couldn't get reset GPIO\n",
-   bus->id);
+   err = PTR_ERR(gpiod);
+   if (err != -EPROBE_DEFER)
+   dev_err(&bus->dev, "mii_bus %s couldn't get reset GPIO 
%d\n", bus->id, err);
device_del(&bus->dev);
-   return PTR_ERR(gpiod);
+   return err;
} else  if (gpiod) {
bus->reset_gpiod = gpiod;
 
-- 
2.17.1

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

On Wed, Nov 18, 2020 at 10:57:08PM +0900, Tetsuo Handa wrote:
> Peter, do you have a plan to make this problem actionable?

I don't even know what the problem is.. nor do you. You can keep sending
this bad paper-over-issues patch until you're blue in the face, I'll not
take it for reasons I've explained before.

I've also previously said that the right way to go about this is to
figure out what exactly is consuming these resources and then figure out
how to cure _that_. Blindly increasing the number only enables bad
actors to get away with being bad.

[PATCH] media: admin-guide/pixfmt-meta-rkisp1.rst: pixfmt reference conforming with macro

2020-11-18 Thread Helen Koike

Fix warnings from make htmlddocs:

Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede 
a section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must 
precede a section header)

Fixes: df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer 
format")

Signed-off-by: Helen Koike 
Reported-by: Stephen Rothwell 
---
 Documentation/admin-guide/media/rkisp1.rst   | 4 ++--
 Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/admin-guide/media/rkisp1.rst 
b/Documentation/admin-guide/media/rkisp1.rst
index 42e37ed255f6..2267e4fb475e 100644
--- a/Documentation/admin-guide/media/rkisp1.rst
+++ b/Documentation/admin-guide/media/rkisp1.rst
@@ -86,7 +86,7 @@ the driver through the rkisp_params node to improve image 
quality during a
 video stream.
 The buffer format is defined by struct :c:type:`rkisp1_stat_buffer`, and
 userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A ` as the
+:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A ` as the
 dataformat.
 
 .. _rkisp1_params:
@@ -100,7 +100,7 @@ and others.
 
 The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
 userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_PARAMS ` as the
+:ref:`V4L2_META_FMT_RK_ISP1_PARAMS ` as the
 dataformat.
 
 
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst 
b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
index f3671472d410..922fa1d59898 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
@@ -1,7 +1,7 @@
 .. SPDX-License-Identifier: GPL-2.0
 
-.. _v4l2-meta-fmt-params-rkisp1:
-.. _v4l2-meta-fmt-stat-rkisp1:
+.. _v4l2-meta-fmt-rk-isp1-params:
+.. _v4l2-meta-fmt-rk-isp1-stat-3a:
 
 *
 V4L2_META_FMT_RK_ISP1_PARAMS ('rk1p'), V4L2_META_FMT_RK_ISP1_STAT_3A ('rk1s')
-- 
2.29.2

Re: violating function pointer signature

On Wed, 18 Nov 2020 14:59:29 +0100
Florian Weimer  wrote:

> * Peter Zijlstra:
> 
> > I think that as long as the function is completely empty (it never
> > touches any of the arguments) this should work in practise.
> >
> > That is:
> >
> >   void tp_nop_func(void) { }
> >
> > can be used as an argument to any function pointer that has a void
> > return. In fact, I already do that, grep for __static_call_nop().  
> 
> You can pass it as a function parameter, but in general, you cannot
> call the function with a different prototype.  Even trivial
> differences such as variadic vs non-variadic prototypes matter.

In this case, I don't believe we need to worry about that, for either
tracepoints or static calls. As both don't have any variadic functions.

The function prototypes are defined by macros. For tracepoints, it's
TP_PROTO() and they require matching arguments. And to top it off, the
functions defined, are added to an array of indirect functions and called
separately. It would take a bit of work to even allow tracepoint callbacks
to be variadic functions. The same is true for static calls I believe.

Thus, all functions will be non-variadic in these cases.

> 
> The default Linux calling conventions are all of the cdecl family,
> where the caller pops the argument off the stack.  You didn't quote
> enough to context to tell whether other calling conventions matter in
> your case.
> 
> > I'm not sure what the LLVM-CFI crud makes of it, but that's their
> > problem.  
> 
> LTO can cause problems as well, particularly with whole-program
> optimization.

Again, for tracepoints and static calls that will likely not be an issue.
Because tracepoint callbacks are function parameters. So are static calls.
What happens is, when you update these locations, you pass in a function
you want as a callback, and it's added to an array (and this code is used
for all tracepoints with all different kinds of prototypes, as the function
is simply a void pointer). Then at the call sites, the function pointers are
typecast to the type of the callback function needed, and called.

It basically can not be optimized even when looking at the entire kernel.

-- Steve

Re: [PATCH] pwm: core: Use octal permission

2020-11-18 Thread Uwe Kleine-König

On Wed, Nov 18, 2020 at 07:36:28PM +0530, Soham Biswas wrote:
> On Wed, 18 Nov 2020 at 19:29, Soham Biswas  wrote:
> >
> > Permission bits are easier readable in octal than with using the symbolic 
> > names.
> >
> > Fixes the following warning generated by checkpatch:
> >
> > drivers/pwm/core.c:1341: WARNING: Symbolic permissions 'S_IRUGO' are not 
> > preferred.
> > Consider using octal permissions '0444'.
> >
> > +debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> > &pwm_debugfs_fops);
> >
> > Signed-off-by: Soham Biswas 
> > ---
> >  drivers/pwm/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> > index 1f16f5365d3c..a8eff4b3ee36 100644
> > --- a/drivers/pwm/core.c
> > +++ b/drivers/pwm/core.c
> > @@ -1338,7 +1338,7 @@ DEFINE_SEQ_ATTRIBUTE(pwm_debugfs);
> >
> >  static int __init pwm_debugfs_init(void)
> >  {
> > -   debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> > +   debugfs_create_file("pwm", S_IFREG | 0444, NULL, NULL,
> > &pwm_debugfs_fops);
> >
> > return 0;
> > --
> > 2.29.2
> >
> 
> I passed -v3 to git-send-email but it didn't work it seems.

It only works if you use it with a commit range I guess, i.e. when it
calls git-format-patch itself.

Also I think if you call checkpatch on your own patch (e.g. using:

git format-patch -v3 --stdout | scripts/checkpatch.pl

) it will tell you to break the long line in the commit log.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH v2] iommu/vt-d: avoid unnecessory panic if iommu init fail in tboot system

2020-11-18 Thread Will Deacon

On Tue, 10 Nov 2020 15:19:08 +0800, Zhenzhong Duan wrote:
> "intel_iommu=off" command line is used to disable iommu but iommu is force
> enabled in a tboot system for security reason.
> 
> However for better performance on high speed network device, a new option
> "intel_iommu=tboot_noforce" is introduced to disable the force on.
> 
> By default kernel should panic if iommu init fail in tboot for security
> reason, but it's unnecessory if we use "intel_iommu=tboot_noforce,off".
> 
> [...]

Applied to arm64 (for-next/iommu/fixes), thanks!

[1/1] iommu/vt-d: Avoid panic if iommu init fails in tboot system
  https://git.kernel.org/arm64/c/4d213e76a359

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

Re: [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v3

2020-11-18 Thread Frederic Weisbecker

On Wed, Nov 18, 2020 at 03:05:03PM +0100, Peter Zijlstra wrote:
> On Wed, Nov 18, 2020 at 02:48:26PM +0100, Frederic Weisbecker wrote:
> > On Wed, Nov 18, 2020 at 08:39:47AM +0100, Peter Zijlstra wrote:
> > > On Tue, Nov 17, 2020 at 04:16:32PM +0100, Frederic Weisbecker wrote:
> > > > Frederic Weisbecker (5):
> > > >   context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACK
> > > >   context_tracking:  Don't implement exception_enter/exit() on 
> > > > CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK
> > > >   sched: Detect call to schedule from critical entry code
> > > >   context_tracking: Only define schedule_user() on 
> > > > !HAVE_CONTEXT_TRACKING_OFFSTACK archs
> > > >   x86: Support HAVE_CONTEXT_TRACKING_OFFSTACK
> > > 
> > > Thanks!
> > > 
> > > Acked-by: Peter Zijlstra (Intel) 
> > 
> > Thanks! Probably this should go through your branches?
> 
> Fair enough; these are now headed for tip/core/entry.

Thanks a lot! :)

[PATCH] bus: ti-sysc: suppress err msg for timers used as clockevent/source

GP Timers used as clockevent/source are not available for ti-sysc bus and
handled by Kernel timekeeping core. Now ti-sysc produces error message
every time such timer is detected:

 "ti-sysc: probe of 4804.target-module failed with error -16"

Such messages are not necessary, so suppress them by returning -ENXIO
instead of -EBUSY.

Signed-off-by: Grygorii Strashko 
---
 drivers/bus/ti-sysc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
index 792a2878cb16..02186bac1b0b 100644
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -2883,7 +2883,7 @@ static int sysc_check_active_timer(struct sysc *ddata)
 
if ((ddata->cfg.quirks & SYSC_QUIRK_NO_RESET_ON_INIT) &&
(ddata->cfg.quirks & SYSC_QUIRK_NO_IDLE))
-   return -EBUSY;
+   return -ENXIO;
 
return 0;
 }
-- 
2.17.1

Re: violating function pointer signature

2020-11-18 Thread Florian Weimer

* Peter Zijlstra:

>> The default Linux calling conventions are all of the cdecl family,
>> where the caller pops the argument off the stack.  You didn't quote
>> enough to context to tell whether other calling conventions matter in
>> your case.
>
> This is strictly in-kernel, and I think we're all cdecl, of which the
> important part is caller-cleanup. The function compiles to:
>
>   RET
>
> so whatever the arguments are is irrelevant.

Yes, then the stub is ABI-compatible, as far as I know.

Re: linux-next: manual merge of the gpio tree with the kspp-gustavo tree

2020-11-18 Thread Andy Shevchenko

On Wed, Nov 18, 2020 at 05:00:57AM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 18, 2020 at 12:52:25PM +0200, Andy Shevchenko wrote:
> > On Wed, Nov 18, 2020 at 11:29 AM Andy Shevchenko
> >  wrote:
> > > On Wed, Nov 18, 2020 at 9:53 AM Linus Walleij  
> > > wrote:
> > > > On Wed, Nov 18, 2020 at 4:24 AM Stephen Rothwell 
> > > >  wrote:
> > > >
> > > > >   b8e0b635e6e6 ("gpio: Fix fall-through warnings for Clang")
> > > > >
> > > > > from the kspp-gustavo tree and commit:
> > 
> > Gustavo, one remark though. It's not okay to hide changes from
> > maintainers. I have checked
> > b8e0b635e6e6 ("gpio: Fix fall-through warnings for Clang") and found
> > nothing except your SoB.
> > 
> > Please, inform maintainers about changes you are doing in their realm(s).
> 
> Sorry about that. I'll remove that change from my tree. I just wanted to
> test some changes in linux-next.
> 
> Thanks for the feedback.

No problem, thanks for taking care of this.

As Linus mentioned, please send a formal patch he will include in his tree.
(I have noticed that there are two drivers in the same change, I recommend
 to split, so should be two separated patches)

-- 
With Best Regards,
Andy Shevchenko

[PATCH][next] scsi: lpfc: Fix memory leak on lcb_context

From: Colin Ian King 

Currently there is an error return path that neglects to free the
allocation for lcb_context.  Fix this by adding a new error free
exit path that kfree's lcb_context before returning.  Use this new
kfree exit path in another exit error path that also kfree's the same
object, allowing a line of code to be removed.

Addresses-Coverity: ("Resource leak")
Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking")
Signed-off-by: Colin Ian King 
---
 drivers/scsi/lpfc/lpfc_els.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 03f47d1b21fe..0d3271b4c130 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -6515,18 +6515,20 @@ lpfc_els_rcv_lcb(struct lpfc_vport *vport, struct 
lpfc_iocbq *cmdiocb,
lcb_context->ndlp = lpfc_nlp_get(ndlp);
if (!lcb_context->ndlp) {
rjt_err = LSRJT_UNABLE_TPC;
-   goto rjt;
+   goto rjt_free;
}
 
if (lpfc_sli4_set_beacon(vport, lcb_context, state)) {
lpfc_printf_vlog(ndlp->vport, KERN_ERR, LOG_TRACE_EVENT,
 "0193 failed to send mail box");
-   kfree(lcb_context);
lpfc_nlp_put(ndlp);
rjt_err = LSRJT_UNABLE_TPC;
-   goto rjt;
+   goto rjt_free;
}
return 0;
+
+rjt_free:
+   kfree(lcb_context);
 rjt:
memset(&stat, 0, sizeof(stat));
stat.un.b.lsRjtRsnCode = rjt_err;
-- 
2.28.0

Re: violating function pointer signature

On Wed, Nov 18, 2020 at 02:59:29PM +0100, Florian Weimer wrote:
> * Peter Zijlstra:
> 
> > I think that as long as the function is completely empty (it never
> > touches any of the arguments) this should work in practise.
> >
> > That is:
> >
> >   void tp_nop_func(void) { }
> >
> > can be used as an argument to any function pointer that has a void
> > return. In fact, I already do that, grep for __static_call_nop().
> 
> You can pass it as a function parameter, but in general, you cannot
> call the function with a different prototype.  Even trivial
> differences such as variadic vs non-variadic prototypes matter.

I don't think any tracepoint uses variadic argument.

> The default Linux calling conventions are all of the cdecl family,
> where the caller pops the argument off the stack.  You didn't quote
> enough to context to tell whether other calling conventions matter in
> your case.

This is strictly in-kernel, and I think we're all cdecl, of which the
important part is caller-cleanup. The function compiles to:

RET

so whatever the arguments are is irrelevant.

> > I'm not sure what the LLVM-CFI crud makes of it, but that's their
> > problem.
> 
> LTO can cause problems as well, particularly with whole-program
> optimization.

I don't think LTO can de-virtualize a dynamic array of function
pointers, so there's very little risk. That said, the __static_call_nop
case, where everything is inlined, is compiled sub-optimally for both
LLVM and GCC.

Re: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform driver

2020-11-18 Thread Krzysztof Kozlowski

On Wed, Nov 18, 2020 at 02:07:41PM +, Alice Guo wrote:
> 
> 
> > -Original Message-
> > From: Krzysztof Kozlowski 
> > Sent: 2020年11月18日 18:42
> > To: Alice Guo 
> > Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> > dl-linux-imx ; Peng Fan ;
> > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org
> > Subject: Re: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform
> > driver
> > 
> > Caution: EXT Email
> > 
> > On Wed, Nov 18, 2020 at 10:28:47AM +, Alice Guo wrote:
> >  >
> > > > If it is properly explained and there is no other way then yes, you
> > > > could. Here, for old DTBs, I would prefer to use
> > > > of_platform_device_create() and bind to "soc" node (child of root).
> > > > This way you would always have device and exactly one entry point
> > > > for the probe.
> > > >
> > >
> > > static struct platform_driver imx8_soc_init_driver = {
> > >   .probe = imx8_soc_init_probe,
> > >   .driver = {
> > >   .name = "soc@0",
> > >   },
> > > };
> > > Can I use "soc@0" to match this driver? It will not use
> > > of_platform_device_create(). It will use of_find_property() to
> > > determine whether and nvmem-cells can be used. If there is no nvmem-cells,
> > it will use the old way, which supports old DTBS. There is no need to add 
> > new
> > compatible.
> > 
> > No, the soc@0 is not a proper name for the driver.
> 
> I have no good idea, please give suggestion. Should I still add new 
> compatible?
> Should I still keep device_initcall? If use of_platform_device_create(), which
> node should I use?

I mentioned my idea in the email before - of_platform_device_create() to
bind to the soc node. This will have to be in the initcall, you don't
have a choice to avoid it, since there was no compatible before.

Best regards,
Krzysztof

[PATCHv2 0/5] Extend Intel service layer, FPGA manager and region

From: Richard Gong 

This is 2nd submission of Intel service layer and FPGA patches.

The customer wants to verify that a FPGA bitstream can be started properly
before saving the bitstream to the QSPI flash memory.

Bitstream authentication makes sure a signed bitstream has valid signatures.

The customer sends the bitstream via FPGA framework and overlay, the
firmware will authenticate the bitstream but not program the bitstream to
device. If the authentication passes, the bitstream will be programmed into
QSPI flash and will be expected to boot without issues.

Extend Intel service layer, FPGA manager and region drivers to support the
bitstream authentication feature.

Richard Gong (5):
  firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag
  fpga: fpga-mgr: add FPGA_MGR_BITSTREM_AUTHENTICATION flag
  fpga: of-fpga-region: add authenticate-fpga-config property
  dt-bindings: fpga: add authenticate-fpga-config property
  fpga: stratix10-soc: entend driver for bitstream authentication

 Documentation/devicetree/bindings/fpga/fpga-region.txt |  1 +
 drivers/fpga/of-fpga-region.c  |  3 +++
 drivers/fpga/stratix10-soc.c   |  3 +++
 include/linux/firmware/intel/stratix10-svc-client.h| 11 ---
 include/linux/fpga/fpga-mgr.h  | 13 -
 5 files changed, 23 insertions(+), 8 deletions(-)

-- 
2.7.4

[PATCHv2 5/5] fpga: stratix10-soc: extend driver for bitstream authentication

From: Richard Gong 

Extend FPGA manager driver to support FPGA bitstream authentication on
Intel SocFPGA platforms.

Signed-off-by: Richard Gong 
---
v2: use flag defined in stratix10-svc driver
---
 drivers/fpga/stratix10-soc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
index 657a70c..b77067e 100644
--- a/drivers/fpga/stratix10-soc.c
+++ b/drivers/fpga/stratix10-soc.c
@@ -186,6 +186,9 @@ static int s10_ops_write_init(struct fpga_manager *mgr,
if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
dev_dbg(dev, "Requesting partial reconfiguration.\n");
ctype.flags |= BIT(COMMAND_RECONFIG_FLAG_PARTIAL);
+   } else if (info->flags & FPGA_MGR_BITSTREM_AUTHENTICATION) {
+   dev_dbg(dev, "Requesting bitstream authentication.\n");
+   ctype.flags |= BIT(COMMAND_AUTHENTICATE_BITSTREAM);
} else {
dev_dbg(dev, "Requesting full reconfiguration.\n");
}
-- 
2.7.4

[PATCHv2 3/5] fpga: of-fpga-region: add authenticate-fpga-config property

From: Richard Gong 

Add authenticate-fpga-config property to support FPGA bitstream
authentication, which makes sure a signed bitstream has valid signatures.

Signed-off-by: Richard Gong 
---
v2: changed in alphabetical order
---
 drivers/fpga/of-fpga-region.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
index e405309..3840883 100644
--- a/drivers/fpga/of-fpga-region.c
+++ b/drivers/fpga/of-fpga-region.c
@@ -219,6 +219,9 @@ static struct fpga_image_info *of_fpga_region_parse_ov(
info->overlay = overlay;
 
/* Read FPGA region properties from the overlay */
+   if (of_property_read_bool(overlay, "authenticate-fpga-config"))
+   info->flags |= FPGA_MGR_BITSTREM_AUTHENTICATION;
+
if (of_property_read_bool(overlay, "partial-fpga-config"))
info->flags |= FPGA_MGR_PARTIAL_RECONFIG;
 
-- 
2.7.4

[PATCHv2 4/5] dt-bindings: fpga: add authenticate-fpga-config property

From: Richard Gong 

Add authenticate-fpga-config property for FPGA bitstream authentication,
which makes sure a signed bitstream has valid signatures.

Signed-off-by: Richard Gong 
---
v2: put authenticate-fpga-config above partial-fpga-config
update commit messages
---
 Documentation/devicetree/bindings/fpga/fpga-region.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
b/Documentation/devicetree/bindings/fpga/fpga-region.txt
index e811cf8..d0d3234 100644
--- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -182,6 +182,7 @@ Optional properties:
This property is optional if the FPGA Manager handles the bridges.
 If the fpga-region is  the child of a fpga-bridge, the list should not
 contain the parent bridge.
+- authenticate-fpga-config : boolean, set if do bitstream authentication only.
 - partial-fpga-config : boolean, set if partial reconfiguration is to be done,
otherwise full reconfiguration is done.
 - external-fpga-config : boolean, set if the FPGA has already been configured
-- 
2.7.4

[PATCHv2 2/5] fpga: fpga-mgr: add FPGA_MGR_BITSTREM_AUTHENTICATION flag

From: Richard Gong 

Add FPGA_MGR_BITSTREM_AUTHENTICATION flag for FPGA bitstream
authentication, which makes sure a signed bitstream has valid signatures.

Except for the actual configuration of the device, the authentication works
the same way as FPGA configuration does. If the authentication passes, the
bitstream will be programmed into QSPI flash and will be expected to boot
without issues.

Signed-off-by: Richard Gong 
---
v2: align all FPGA_MGR_* flags
update the commit messages
---
 include/linux/fpga/fpga-mgr.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 2bc3030..4fb3400 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -67,12 +67,15 @@ enum fpga_mgr_states {
  * %FPGA_MGR_BITSTREAM_LSB_FIRST: SPI bitstream bit order is LSB first
  *
  * %FPGA_MGR_COMPRESSED_BITSTREAM: FPGA bitstream is compressed
+ *
+ * %FPGA_MGR_BITSTREM_AUTHENTICATION: do FPGA bitstream authentication only
  */
-#define FPGA_MGR_PARTIAL_RECONFIG  BIT(0)
-#define FPGA_MGR_EXTERNAL_CONFIG   BIT(1)
-#define FPGA_MGR_ENCRYPTED_BITSTREAM   BIT(2)
-#define FPGA_MGR_BITSTREAM_LSB_FIRST   BIT(3)
-#define FPGA_MGR_COMPRESSED_BITSTREAM  BIT(4)
+#define FPGA_MGR_PARTIAL_RECONFIG  BIT(0)
+#define FPGA_MGR_EXTERNAL_CONFIG   BIT(1)
+#define FPGA_MGR_ENCRYPTED_BITSTREAM   BIT(2)
+#define FPGA_MGR_BITSTREAM_LSB_FIRST   BIT(3)
+#define FPGA_MGR_COMPRESSED_BITSTREAM  BIT(4)
+#define FPGA_MGR_BITSTREM_AUTHENTICATION   BIT(5)
 
 /**
  * struct fpga_image_info - information specific to a FPGA image
-- 
2.7.4

[PATCHv2 1/5] firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag

From: Richard Gong 

Add COMMAND_AUTHENTICATE_BITSTREAM command flag for new added bitstream
authentication feature. Authenticating a bistream is to make sure a signed
bitstream has the valid signatures.

Except for the actual configuration of the device, the bitstream
authentication works the same way as FPGA configuration does. If the
authentication passes, the signed bitstream will be programmed into QSPI
flash memory and will be expected to boot without issues.

Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which
aligns with the firmware settings.

Signed-off-by: Richard Gong 
---
v2: new added
---
 include/linux/firmware/intel/stratix10-svc-client.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/linux/firmware/intel/stratix10-svc-client.h 
b/include/linux/firmware/intel/stratix10-svc-client.h
index a93d859..85463c8 100644
--- a/include/linux/firmware/intel/stratix10-svc-client.h
+++ b/include/linux/firmware/intel/stratix10-svc-client.h
@@ -51,12 +51,17 @@
 #define SVC_STATUS_NO_SUPPORT  6
 
 /**
- * Flag bit for COMMAND_RECONFIG
+ * Flag bit for COMMAND_RECONFIG, in bit number
  *
  * COMMAND_RECONFIG_FLAG_PARTIAL:
- * Set to FPGA configuration type (full or partial).
+ * Set for partial FPGA configuration.
+ *
+ * COMMAND_AUTHENTICATE_BITSTREAM:
+ * Set for bitstream authentication, which makes sure a signed bitstream
+ * has valid signatures before committing it to QSPI flash memory.
  */
-#define COMMAND_RECONFIG_FLAG_PARTIAL  1
+#define COMMAND_RECONFIG_FLAG_PARTIAL  0
+#define COMMAND_AUTHENTICATE_BITSTREAM 1
 
 /**
  * Timeout settings for service clients:
-- 
2.7.4

RE: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform driver

2020-11-18 Thread Alice Guo



> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: 2020年11月18日 18:42
> To: Alice Guo 
> Cc: robh...@kernel.org; shawn...@kernel.org; s.ha...@pengutronix.de;
> dl-linux-imx ; Peng Fan ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v3 4/4] soc: imx8m: change to use platform
> driver
> 
> Caution: EXT Email
> 
> On Wed, Nov 18, 2020 at 10:28:47AM +, Alice Guo wrote:
>  >
> > > If it is properly explained and there is no other way then yes, you
> > > could. Here, for old DTBs, I would prefer to use
> > > of_platform_device_create() and bind to "soc" node (child of root).
> > > This way you would always have device and exactly one entry point
> > > for the probe.
> > >
> >
> > static struct platform_driver imx8_soc_init_driver = {
> >   .probe = imx8_soc_init_probe,
> >   .driver = {
> >   .name = "soc@0",
> >   },
> > };
> > Can I use "soc@0" to match this driver? It will not use
> > of_platform_device_create(). It will use of_find_property() to
> > determine whether and nvmem-cells can be used. If there is no nvmem-cells,
> it will use the old way, which supports old DTBS. There is no need to add new
> compatible.
> 
> No, the soc@0 is not a proper name for the driver.

I have no good idea, please give suggestion. Should I still add new compatible?
Should I still keep device_initcall? If use of_platform_device_create(), which
node should I use?

Best regards,
Alice Guo

> Best regards,
> Krzysztof

Re: [PATCH] pwm: core: Use octal permission

2020-11-18 Thread Soham Biswas

On Wed, 18 Nov 2020 at 19:29, Soham Biswas  wrote:
>
> Permission bits are easier readable in octal than with using the symbolic 
> names.
>
> Fixes the following warning generated by checkpatch:
>
> drivers/pwm/core.c:1341: WARNING: Symbolic permissions 'S_IRUGO' are not 
> preferred.
> Consider using octal permissions '0444'.
>
> +debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> &pwm_debugfs_fops);
>
> Signed-off-by: Soham Biswas 
> ---
>  drivers/pwm/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index 1f16f5365d3c..a8eff4b3ee36 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -1338,7 +1338,7 @@ DEFINE_SEQ_ATTRIBUTE(pwm_debugfs);
>
>  static int __init pwm_debugfs_init(void)
>  {
> -   debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> +   debugfs_create_file("pwm", S_IFREG | 0444, NULL, NULL,
> &pwm_debugfs_fops);
>
> return 0;
> --
> 2.29.2
>

I passed -v3 to git-send-email but it didn't work it seems.

Re: [EXTERNAL] [tip: x86/apic] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-18 Thread Thomas Gleixner

Suravee,

On Wed, Nov 18 2020 at 17:29, Suravee Suthikulpanit wrote:
> On 11/17/20 9:00 AM, Suravee Suthikulpanit wrote:
>
> I might need your help debugging this issue. I'm seeing the following error:
>
> [   14.005937] irq 29, desc: d200500b, depth: 0, count: 0, unhandled: > 0
> [   14.006234] ->handle_irq():  eab4b6eb, handle_bad_irq+0x0/0x230
> [   14.006234] ->irq_data.chip(): 1cce6d6b, 
> intcapxt_controller+0x0/0x120
> [   14.006234] ->action(): 83bfd734
> [   14.006234] ->action->handler(): 94806345, 
> amd_iommu_int_handler+0x0/0x10
> [   14.006234] unexpected IRQ trap at vector 1d
>
> Do you have any idea what might have gone wrong here?

Yes. This lacks setting up the low level flow handler. Delta patch
below.

Thanks,

tglx
---
--- a/drivers/iommu/amd/init.c
+++ b/drivers/iommu/amd/init.c
@@ -2033,6 +2033,7 @@ static int intcapxt_irqdomain_alloc(stru
 
irqd->chip = &intcapxt_controller;
irqd->chip_data = info->data;
+   __irq_set_handler(i, handle_edge_irq, 0, "edge");
}
 
return ret;

Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI interrupt link

2020-11-18 Thread Chen Baozi

Hi Lorenzo,

> On Nov 18, 2020, at 5:51 PM, Lorenzo Pieralisi  
> wrote:
> 
> On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
>> Some PCIe designs require software to do extra acknowledgements for
>> legacy INTx interrupts. If the driver is written only for device tree,
>> things are simple. In that case, a new driver can be written under
>> driver/pci/controller/ with a DT node of PCIe host written like:
>> 
>>  pcie {
>>...
>>interrupt-map = <0 0 0  1  &pcie_intc 0>,
>><0 0 0  2  &pcie_intc 1>,
>><0 0 0  3  &pcie_intc 2>,
>><0 0 0  4  &pcie_intc 3>;
>> 
>>pcie_intc: legacy-interrupt-controller {
>>  interrupt-controller;
>>  #interrupt-cells = <1>;
>>  interrupt-parent = <&gic>;
>>  interrupts = <0 226 4>;
>>};
>>  };
>> 
>> Similar designs can be found on Aardvark, MediaTek Gen2 and Socionext
>> UniPhier PCIe controller at the moment. Essentially, those designs are
>> supported by inserting an extra interrupt controller between PCIe host
>> and GIC and parse the topology in a DT-based PCI controller driver.
>> As we turn to ACPI, All the PCIe hosts are described the same ID of
>> "PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
>> to make this kind of PCI INTx work under ACPI.
> 
> In this respect this patch is a minor detail. The major detail is how
> those host controllers are going to probe and initialize with ACPI and I
> am against merging this patch stand alone with no user before
> understanding what you really want to do with those host controller
> drivers in the ACPI world.
> 
> Side note, there is ongoing work for a generic interrupt MUX:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=2995
> 
> If we ever come to support those MUXes with ACPI that must be a
> starting point, the binding above can be your first "user".
> 
> I still have reservations about bootstrapping the host controllers
> you mentioned in platforms with no firmware support whatsoever for
> PCI initialization (eg address decoders, link bring-up, etc. - the
> ACPI host bridge model relies on FW to carry out that initialization)
> with ACPI - I would like to see the whole picture first.

Frankly, I’m also waiting for my first “user” to be announced at the moment,
so that I can make the whole picture clearer. And it is why I mark this
patch as an RFC. 

Yes. I admit it is a little weird to add another interrupt controller
between the GIC and INTx device. But if it is not only about
initialization but also about hooking into the INTx processing (e.g.,
introduce an extra ack operation...), it seems we cannot only rely
on FW. I have looked for a FW solution without introducing a new
driver later but failed... I’m happy to be fixed if there is a pure
FW solution.

Thanks.

Baozi.

Re: [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v3

On Wed, Nov 18, 2020 at 02:48:26PM +0100, Frederic Weisbecker wrote:
> On Wed, Nov 18, 2020 at 08:39:47AM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 17, 2020 at 04:16:32PM +0100, Frederic Weisbecker wrote:
> > > Frederic Weisbecker (5):
> > >   context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACK
> > >   context_tracking:  Don't implement exception_enter/exit() on 
> > > CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK
> > >   sched: Detect call to schedule from critical entry code
> > >   context_tracking: Only define schedule_user() on 
> > > !HAVE_CONTEXT_TRACKING_OFFSTACK archs
> > >   x86: Support HAVE_CONTEXT_TRACKING_OFFSTACK
> > 
> > Thanks!
> > 
> > Acked-by: Peter Zijlstra (Intel) 
> 
> Thanks! Probably this should go through your branches?

Fair enough; these are now headed for tip/core/entry.

[PATCH v2 0/3] Add bus format negotiation support for Cadence MHDP8546 driver

This patch series add bus format negotiation support for Cadence MHDP8546
bridge driver.

The patch series has four patches in the below sequence:
1. drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge
function.
Return all the input formats supported.
2. drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector
info
Remove the bus format configuration using connector info structure.
3. drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus
format
Get the pixel format and bpc based on negotiated output bus format.

This patch series is dependent on tidss series [1] for the new connector model
support.

[1]

https://patchwork.kernel.org/project/dri-devel/cover/20201109170601.21557-1-nikhil...@ti.com/

Version History:

v2:
- Remove the Add output bus format negotiation patch from the series,
as we use ouput format as MEDIA_BUS_FMT_FIXED and that is the
default value if atomic_get_output_bus_fmts function is not implemented.
- Return NULL if output format is not MEDIA_BUS_FMT_FIXED.
- Return the supported color formats based on the display info structure.

Yuti Amonkar (3):
drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge
function
drm: bridge: cdns-mhdp8546: Remove setting of bus format using
connector info
drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on
bus format

.../drm/bridge/cadence/cdns-mhdp8546-core.c | 133 +-
1 file changed, 99 insertions(+), 34 deletions(-)

--
2.17.1

[PATCH v2 1/3] drm: bridge: cdns-mhdp8546: Modify atomic_get_input_bus_format bridge function

Modify atomic_get_input_bus_format function to return input formats
supported instead of using hardcoded value.

Signed-off-by: Yuti Amonkar 
---
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 45 ++-
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 6beccd2a408e..7c80555ab4ab 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -2078,27 +2078,52 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge *bridge)
return &cdns_mhdp_state->base;
 }
 
+#define MAX_INPUT_FORMAT 11
+
 static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
- struct drm_bridge_state *bridge_state,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state,
- u32 output_fmt,
- unsigned int *num_input_fmts)
-{
+struct drm_bridge_state *bridge_state,
+struct drm_crtc_state *crtc_state,
+struct drm_connector_state *conn_state,
+u32 output_fmt,
+unsigned int *num_input_fmts)
+{
+   struct drm_connector *conn = conn_state->connector;
+   struct drm_display_info *info = &conn->display_info;
u32 *input_fmts;
-   u32 default_bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
+   unsigned int i = 0;
 
*num_input_fmts = 0;
 
if (output_fmt != MEDIA_BUS_FMT_FIXED)
return NULL;
 
-   input_fmts = kzalloc(sizeof(*input_fmts), GFP_KERNEL);
+   input_fmts = kcalloc(MAX_INPUT_FORMAT,
+sizeof(*input_fmts), GFP_KERNEL);
if (!input_fmts)
return NULL;
 
-   *num_input_fmts = 1;
-   input_fmts[0] = default_bus_format;
+   if (info->color_formats & DRM_COLOR_FORMAT_RGB444) {
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36;
+   input_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48;
+   }
+
+   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB444) {
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36;
+   input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48;
+   }
+
+   if (info->color_formats & DRM_COLOR_FORMAT_YCRCB422) {
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16;
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20;
+   input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24;
+   }
+
+   *num_input_fmts = i;
+
return input_fmts;
 }
 
-- 
2.17.1

[PATCH v2 3/3] drm: bridge: cdns-mhdp8546: Retrieve the pixel format and bpc based on bus format

Get the pixel format and bpc based on the output bus format
negotiated instead of hardcoding the values.

Signed-off-by: Yuti Amonkar 
---
 .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 82 +++
 1 file changed, 64 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index d5e94bd74df1..e1f4bbd09816 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1512,24 +1512,8 @@ static int cdns_mhdp_get_modes(struct drm_connector 
*connector)
 
drm_connector_update_edid_property(connector, edid);
num_modes = drm_add_edid_modes(connector, edid);
-   kfree(edid);
 
-   /*
-* HACK: Warn about unsupported display formats until we deal
-*   with them correctly.
-*/
-   if (connector->display_info.color_formats &&
-   !(connector->display_info.color_formats &
- mhdp->display_fmt.color_format))
-   dev_warn(mhdp->dev,
-"%s: No supported color_format found (0x%08x)\n",
-   __func__, connector->display_info.color_formats);
-
-   if (connector->display_info.bpc &&
-   connector->display_info.bpc < mhdp->display_fmt.bpc)
-   dev_warn(mhdp->dev, "%s: Display bpc only %d < %d\n",
-__func__, connector->display_info.bpc,
-mhdp->display_fmt.bpc);
+   kfree(edid);
 
return num_modes;
 }
@@ -1689,6 +1673,66 @@ static int cdns_mhdp_attach(struct drm_bridge *bridge,
return 0;
 }
 
+static void cdns_mhdp_get_display_fmt(struct cdns_mhdp_device *mhdp,
+ struct drm_bridge_state *state)
+{
+   u32 bus_fmt, bpc, pxlfmt;
+
+   bus_fmt = state->output_bus_cfg.format;
+   switch (bus_fmt) {
+   case MEDIA_BUS_FMT_RGB161616_1X48:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 16;
+   break;
+   case MEDIA_BUS_FMT_YUV16_1X48:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 16;
+   break;
+   case MEDIA_BUS_FMT_RGB121212_1X36:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_UYVY12_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_YUV12_1X36:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 12;
+   break;
+   case MEDIA_BUS_FMT_RGB101010_1X30:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_UYVY10_1X20:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_YUV10_1X30:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 10;
+   break;
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 8;
+   break;
+   case MEDIA_BUS_FMT_UYVY8_1X16:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB422;
+   bpc = 8;
+   break;
+   case MEDIA_BUS_FMT_YUV8_1X24:
+   pxlfmt = DRM_COLOR_FORMAT_YCRCB444;
+   bpc = 8;
+   break;
+   default:
+   pxlfmt = DRM_COLOR_FORMAT_RGB444;
+   bpc = 8;
+   }
+
+   mhdp->display_fmt.color_format = pxlfmt;
+   mhdp->display_fmt.bpc = bpc;
+}
+
 static void cdns_mhdp_configure_video(struct cdns_mhdp_device *mhdp,
  const struct drm_display_mode *mode)
 {
@@ -2129,6 +2173,8 @@ static int cdns_mhdp_atomic_check(struct drm_bridge 
*bridge,
struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
 
+   cdns_mhdp_get_display_fmt(mhdp, bridge_state);
+
mutex_lock(&mhdp->link_mutex);
 
if (!cdns_mhdp_bandwidth_ok(mhdp, mode, mhdp->link.num_lanes,
@@ -2456,7 +2502,7 @@ static int cdns_mhdp_probe(struct platform_device *pdev)
mhdp->link.rate = mhdp->host.link_rate;
mhdp->link.num_lanes = mhdp->host.lanes_cnt;
 
-   /* The only currently supported format */
+   /* Initialize color format bpc and y_only to default values*/
mhdp->display_fmt.y_only = false;
mhdp->display_fmt.color_format = DRM_COLOR_FORMAT_RGB444;
mhdp->display_fmt.bpc = 8;
-- 
2.17.1

[PATCH] x86/msr: Filter MSR writes

2020-11-18 Thread Mathieu Chouquet-Stringer

On Wed, Nov 18, 2020 at 12:50:27PM +0100, Borislav Petkov wrote:
> On Wed, Nov 18, 2020 at 10:09:29AM +0100, Mathieu Chouquet-Stringer wrote:
> > Speaking of doc, looking at the patches you submitted, I didn't see any
> > update to the documentation. Would you like me to create a patch for
> > that?
> 
> Sure, that would be appreciated.

Here you go, let me know if I got that right...

---
TAINT_CPU_OUT_OF_SPEC now means what it says. Historically it was for
SMP kernel oops on an officially SMP incapable processor but now it also
covers CPUs whose MSRs have been incorrectly poked at. Update
documentation and script to reflect that.

Signed-off-by: Mathieu Chouquet-Stringer 
---
 Documentation/admin-guide/tainted-kernels.rst | 11 ++-
 tools/debugging/kernel-chktaint   |  2 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/admin-guide/tainted-kernels.rst 
b/Documentation/admin-guide/tainted-kernels.rst
index f718a2eaf1f6..95f432c43ba0 100644
--- a/Documentation/admin-guide/tainted-kernels.rst
+++ b/Documentation/admin-guide/tainted-kernels.rst
@@ -84,7 +84,7 @@ Bit  Log  Number  Reason that got the kernel tainted
 ===  ===  ==  
   0  G/P   1  proprietary module was loaded
   1  _/F   2  module was force loaded
-  2  _/S   4  SMP kernel oops on an officially SMP incapable processor
+  2  _/S   4  kernel running on out of spec processor
   3  _/R   8  module was force unloaded
   4  _/M  16  processor reported a Machine Check Exception (MCE)
   5  _/B  32  bad page referenced or some unexpected page flags
@@ -116,10 +116,11 @@ More detailed explanation for tainting
  1)  ``F`` if any module was force loaded by ``insmod -f``, ``' '`` if all
  modules were loaded normally.
 
- 2)  ``S`` if the oops occurred on an SMP kernel running on hardware that
- hasn't been certified as safe to run multiprocessor.
- Currently this occurs only on various Athlons that are not
- SMP capable.
+ 2)  ``S`` if the kernel is running on any processor that is out of
+ specifications (writing to MSRs will trigger this behavior).
+ Historically, it could also be if an oops occured on a kernel running on
+ hardware that hasn't been certified as safe to run multiprocessor, such
+ as various Athlons that are not SMP capable.
 
  3)  ``R`` if a module was force unloaded by ``rmmod -f``, ``' '`` if all
  modules were unloaded normally.
diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
index 2240cb56e6e5..0b9d93e27910 100755
--- a/tools/debugging/kernel-chktaint
+++ b/tools/debugging/kernel-chktaint
@@ -72,7 +72,7 @@ if [ `expr $T % 2` -eq 0 ]; then
addout " "
 else
addout "S"
-   echo " * SMP kernel oops on an officially SMP incapable processor (#2)"
+   echo " * kernel running on out of spec processor (#2)"
 fi
 
 T=`expr $T / 2`

[PATCH v2 2/3] drm: bridge: cdns-mhdp8546: Remove setting of bus format using connector info

As we are using bus negotiations for selecting bus format
remove the setting of bus format using the connector info
structure.

Signed-off-by: Yuti Amonkar 
---
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 7c80555ab4ab..d5e94bd74df1 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -1630,7 +1630,6 @@ static const struct drm_connector_funcs 
cdns_mhdp_conn_funcs = {
 
 static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
 {
-   u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
struct drm_connector *conn = &mhdp->connector;
struct drm_bridge *bridge = &mhdp->bridge;
int ret;
@@ -1651,11 +1650,6 @@ static int cdns_mhdp_connector_init(struct 
cdns_mhdp_device *mhdp)
 
drm_connector_helper_add(conn, &cdns_mhdp_conn_helper_funcs);
 
-   ret = drm_display_info_set_bus_formats(&conn->display_info,
-  &bus_format, 1);
-   if (ret)
-   return ret;
-
ret = drm_connector_attach_encoder(conn, bridge->encoder);
if (ret) {
dev_err(mhdp->dev, "Failed to attach connector to encoder\n");
-- 
2.17.1

Re: [PATCH v3 1/3] tools/bootconfig: Fix to check the write failure correctly

On Wed, 18 Nov 2020 22:37:08 +0900
Masami Hiramatsu  wrote:

> BTW, I found another bug in bootconfig error handling.
> Steve, did you already pick this series? If not yet, I will update the seires 
> to add that fix.

No, I was about to pull it in today. I'll wait for your new series.

Thanks!

-- Steve

Re: violating function pointer signature

On Wed, 18 Nov 2020 14:21:36 +0100
Peter Zijlstra  wrote:

> I think that as long as the function is completely empty (it never
> touches any of the arguments) this should work in practise.
> 
> That is:
> 
>   void tp_nop_func(void) { }

My original version (the OP of this thread) had this:

+static void tp_stub_func(void)
+{
+   return;
+}

> 
> can be used as an argument to any function pointer that has a void
> return. In fact, I already do that, grep for __static_call_nop().
> 
> I'm not sure what the LLVM-CFI crud makes of it, but that's their
> problem.

If it is already done elsewhere in the kernel, then I will call this
precedence, and keep the original version.

This way Alexei can't complain about adding a check in the fast path of
more than one callback attached.

-- Steve

[PATCH net-next v3 5/6] net/x25: fix restart request/confirm handling

We have to take the actual link state into account to handle
restart requests/confirms well.

Also, the T20 timer needs to be stopped, if the link is terminated.

Signed-off-by: Martin Schiller 
---
 net/x25/x25_link.c | 45 +
 1 file changed, 37 insertions(+), 8 deletions(-)

diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index 92828a8a4ada..40ffc10f7a96 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -74,16 +74,43 @@ void x25_link_control(struct sk_buff *skb, struct x25_neigh 
*nb,
 
switch (frametype) {
case X25_RESTART_REQUEST:
-   confirm = !x25_t20timer_pending(nb);
-   x25_stop_t20timer(nb);
-   nb->state = X25_LINK_STATE_3;
-   if (confirm)
+   switch (nb->state) {
+   case X25_LINK_STATE_2:
+   confirm = !x25_t20timer_pending(nb);
+   x25_stop_t20timer(nb);
+   nb->state = X25_LINK_STATE_3;
+   if (confirm)
+   x25_transmit_restart_confirmation(nb);
+   break;
+   case X25_LINK_STATE_3:
+   /* clear existing virtual calls */
+   x25_kill_by_neigh(nb);
+
x25_transmit_restart_confirmation(nb);
+   break;
+   }
break;
 
case X25_RESTART_CONFIRMATION:
-   x25_stop_t20timer(nb);
-   nb->state = X25_LINK_STATE_3;
+   switch (nb->state) {
+   case X25_LINK_STATE_2:
+   if (x25_t20timer_pending(nb)) {
+   x25_stop_t20timer(nb);
+   nb->state = X25_LINK_STATE_3;
+   } else {
+   x25_transmit_restart_request(nb);
+   x25_start_t20timer(nb);
+   }
+   break;
+   case X25_LINK_STATE_3:
+   /* clear existing virtual calls */
+   x25_kill_by_neigh(nb);
+
+   x25_transmit_restart_request(nb);
+   nb->state = X25_LINK_STATE_2;
+   x25_start_t20timer(nb);
+   break;
+   }
break;
 
case X25_DIAGNOSTIC:
@@ -214,8 +241,6 @@ void x25_link_established(struct x25_neigh *nb)
 {
switch (nb->state) {
case X25_LINK_STATE_0:
-   nb->state = X25_LINK_STATE_2;
-   break;
case X25_LINK_STATE_1:
x25_transmit_restart_request(nb);
nb->state = X25_LINK_STATE_2;
@@ -232,6 +257,10 @@ void x25_link_established(struct x25_neigh *nb)
 void x25_link_terminated(struct x25_neigh *nb)
 {
nb->state = X25_LINK_STATE_0;
+
+   if (x25_t20timer_pending(nb))
+   x25_stop_t20timer(nb);
+
/* Out of order: clear existing virtual calls (X.25 03/93 4.6.3) */
x25_kill_by_neigh(nb);
 }
-- 
2.20.1

Re: [PATCH RESEND v2 0/3] condition EAS enablement on FI support

On Wed, Nov 18, 2020 at 11:42:34AM +, Ionela Voinescu wrote:
> Hi guys,
> 
> On Tuesday 27 Oct 2020 at 18:07:10 (+), Ionela Voinescu wrote:
> > Given the maturity gained by cpufreq-based Frequency Invariance (FI)
> > support following the patches at [1], this series conditions Energy
> > Aware Scheduling (EAS) enablement on a frequency invariant system.
> > 
> > Currently, EAS can be enabled on a system without FI support, leading
> > to incorrect (energy-wise) task placements. As no warning is emitted,
> > it could take some debugging effort to track the behavior back to the
> > lack of FI support; this series changes that by disabling EAS
> > (and advertising it) when FI support is missing.
> > 
> > The series is structured as follows:
> >  - 1/3 - create function that can rebuild the scheduling and EAS'
> >performance domains if EAS' initial conditions change
> >  - 2/3 - arm64: rebuild scheduling and performance domains in the
> >  case of late, counter-driven FI initialisation.
> >  - 3/3 - condition EAS enablement on FI support
> > 
> > RESEND v2: rebase and retest on v5.10-rc1
> > 
> 
> This still applies nicely on v5.10-rc4.
> 
> Peter, given that 1/3 and 2/3 are acked, do you think there's anything
> else that needs to be done for this?

I'll take it, thanks!

[PATCH net-next v3 6/6] net/x25: remove x25_kill_by_device()

Remove unnecessary function x25_kill_by_device().

Replace the call to x25_kill_by_device() by x25_kill_by_neigh().

Therefore, also remove the call to x25_clear_forward_by_dev() in
x25_route_device_down(), as this is already called by
x25_kill_by_neigh().

Signed-off-by: Martin Schiller 
---
 net/x25/af_x25.c| 22 +-
 net/x25/x25_route.c |  3 ---
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 02f56386e05b..ec90956f38d4 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -199,22 +199,6 @@ static void x25_remove_socket(struct sock *sk)
write_unlock_bh(&x25_list_lock);
 }
 
-/*
- * Kill all bound sockets on a dropped device.
- */
-static void x25_kill_by_device(struct net_device *dev)
-{
-   struct sock *s;
-
-   write_lock_bh(&x25_list_lock);
-
-   sk_for_each(s, &x25_list)
-   if (x25_sk(s)->neighbour && x25_sk(s)->neighbour->dev == dev)
-   x25_disconnect(s, ENETUNREACH, 0, 0);
-
-   write_unlock_bh(&x25_list_lock);
-}
-
 /*
  * Handle device status changes.
  */
@@ -260,7 +244,11 @@ static int x25_device_event(struct notifier_block *this, 
unsigned long event,
case NETDEV_DOWN:
pr_debug("X.25: got event NETDEV_DOWN for device: %s\n",
 dev->name);
-   x25_kill_by_device(dev);
+   nb = x25_get_neigh(dev);
+   if (nb) {
+   x25_kill_by_neigh(nb);
+   x25_neigh_put(nb);
+   }
x25_route_device_down(dev);
x25_link_device_down(dev);
break;
diff --git a/net/x25/x25_route.c b/net/x25/x25_route.c
index 00e46c9a5280..ec2a39e9b3e6 100644
--- a/net/x25/x25_route.c
+++ b/net/x25/x25_route.c
@@ -115,9 +115,6 @@ void x25_route_device_down(struct net_device *dev)
__x25_remove_route(rt);
}
write_unlock_bh(&x25_route_list_lock);
-
-   /* Remove any related forwarding */
-   x25_clear_forward_by_dev(dev);
 }
 
 /*
-- 
2.20.1

[PATCH net-next v3 4/6] net/lapb: fix t1 timer handling for DCE

fix t1 timer handling for DCE in LAPB_STATE_0:
 o DTE interface changes immediately to LAPB_STATE_1 and start sending
   SABM(E).
 o DCE interface sends N2-times DM and changes to LAPB_STATE_1
   afterwards if there is no response in the meantime.

Signed-off-by: Martin Schiller 
---
 net/lapb/lapb_timer.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/net/lapb/lapb_timer.c b/net/lapb/lapb_timer.c
index 8f5b17001a07..baa247fe4ed0 100644
--- a/net/lapb/lapb_timer.c
+++ b/net/lapb/lapb_timer.c
@@ -85,11 +85,18 @@ static void lapb_t1timer_expiry(struct timer_list *t)
switch (lapb->state) {
 
/*
-*  If we are a DCE, keep going DM .. DM .. DM
+*  If we are a DCE, send DM up to N2 times, then switch to
+*  STATE_1 and send SABM(E).
 */
case LAPB_STATE_0:
-   if (lapb->mode & LAPB_DCE)
+   if (lapb->mode & LAPB_DCE &&
+   lapb->n2count != lapb->n2) {
+   lapb->n2count++;
lapb_send_control(lapb, LAPB_DM, LAPB_POLLOFF, 
LAPB_RESPONSE);
+   } else {
+   lapb->state = LAPB_STATE_1;
+   lapb_establish_data_link(lapb);
+   }
break;
 
/*
-- 
2.20.1

[PATCH net-next v3 3/6] net/lapb: handle carrier loss correctly

In case of carrier loss, clear all queues, enter state LABB_STATE_0 and
stop all timers.

By setting rc = LAPB_NOTCONNECTED, the upper layer is informed about the
disconnect.

Signed-off-by: Martin Schiller 
---
 net/lapb/lapb_iface.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 8dd7c420ae93..017bc169c334 100644
--- a/net/lapb/lapb_iface.c
+++ b/net/lapb/lapb_iface.c
@@ -303,6 +303,18 @@ int lapb_disconnect_request(struct net_device *dev)
if (!lapb)
goto out;
 
+   if (!netif_carrier_ok(dev)) {
+   lapb_dbg(0, "(%p) Carrier lost!\n", lapb->dev);
+   lapb_dbg(0, "(%p) S%d -> S0\n", lapb->dev, lapb->state);
+   lapb_clear_queues(lapb);
+   lapb->state = LAPB_STATE_0;
+   lapb->n2count = 0;
+   lapb_stop_t1timer(lapb);
+   lapb_stop_t2timer(lapb);
+   rc = LAPB_NOTCONNECTED;
+   goto out_put;
+   }
+
switch (lapb->state) {
case LAPB_STATE_0:
rc = LAPB_NOTCONNECTED;
-- 
2.20.1

[PATCH net-next v3 2/6] net/lapb: fix lapb_connect_request() for DCE

For a DTE interface we should change to state LAPB_STATE_1 and start
sending SABM(E). But for DCE interfaces, we simply should start the
timer t1.

Signed-off-by: Martin Schiller 
---
 net/lapb/lapb_iface.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/net/lapb/lapb_iface.c b/net/lapb/lapb_iface.c
index 3c03f6512c5f..8dd7c420ae93 100644
--- a/net/lapb/lapb_iface.c
+++ b/net/lapb/lapb_iface.c
@@ -278,10 +278,14 @@ int lapb_connect_request(struct net_device *dev)
if (lapb->state == LAPB_STATE_3 || lapb->state == LAPB_STATE_4)
goto out_put;
 
-   lapb_establish_data_link(lapb);
+   if (lapb->mode & LAPB_DCE) {
+   lapb_start_t1timer(lapb);
+   } else {
+   lapb_establish_data_link(lapb);
 
-   lapb_dbg(0, "(%p) S0 -> S1\n", lapb->dev);
-   lapb->state = LAPB_STATE_1;
+   lapb_dbg(0, "(%p) S0 -> S1\n", lapb->dev);
+   lapb->state = LAPB_STATE_1;
+   }
 
rc = LAPB_OK;
 out_put:
-- 
2.20.1

[PATCH net-next v3 1/6] net/x25: handle additional netdev events

Add / remove x25_link_device by NETDEV_REGISTER/UNREGISTER and also by
NETDEV_POST_TYPE_CHANGE/NETDEV_PRE_TYPE_CHANGE.

This change is needed so that the x25_neigh struct for an interface is
already created when it shows up and is kept independently if the
interface goes UP or DOWN.

This is used in an upcomming commit, where x25 params of an neighbour
will get configurable through ioctls.

Additionally the NETDEV_CHANGE event makes it possible to handle carrier
loss and detection.

Signed-off-by: Martin Schiller 
---
 include/net/x25.h  |  2 ++
 net/x25/af_x25.c   | 44 
 net/x25/x25_link.c | 45 +++--
 3 files changed, 85 insertions(+), 6 deletions(-)

diff --git a/include/net/x25.h b/include/net/x25.h
index d7d6c2b4ffa7..4c1502e8b2b2 100644
--- a/include/net/x25.h
+++ b/include/net/x25.h
@@ -231,6 +231,8 @@ int x25_backlog_rcv(struct sock *, struct sk_buff *);
 
 /* x25_link.c */
 void x25_link_control(struct sk_buff *, struct x25_neigh *, unsigned short);
+void x25_link_device_add(struct net_device *dev);
+void x25_link_device_remove(struct net_device *dev);
 void x25_link_device_up(struct net_device *);
 void x25_link_device_down(struct net_device *);
 void x25_link_established(struct x25_neigh *);
diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c
index 046d3fee66a9..02f56386e05b 100644
--- a/net/x25/af_x25.c
+++ b/net/x25/af_x25.c
@@ -233,10 +233,24 @@ static int x25_device_event(struct notifier_block *this, 
unsigned long event,
 #endif
 ) {
switch (event) {
+   case NETDEV_REGISTER:
+   pr_debug("X.25: got event NETDEV_REGISTER for device: 
%s\n",
+dev->name);
+   x25_link_device_add(dev);
+   break;
+   case NETDEV_POST_TYPE_CHANGE:
+   pr_debug("X.25: got event NETDEV_POST_TYPE_CHANGE for 
device: %s\n",
+dev->name);
+   x25_link_device_add(dev);
+   break;
case NETDEV_UP:
+   pr_debug("X.25: got event NETDEV_UP for device: %s\n",
+dev->name);
x25_link_device_up(dev);
break;
case NETDEV_GOING_DOWN:
+   pr_debug("X.25: got event NETDEV_GOING_DOWN for device: 
%s\n",
+dev->name);
nb = x25_get_neigh(dev);
if (nb) {
x25_terminate_link(nb);
@@ -244,10 +258,40 @@ static int x25_device_event(struct notifier_block *this, 
unsigned long event,
}
break;
case NETDEV_DOWN:
+   pr_debug("X.25: got event NETDEV_DOWN for device: %s\n",
+dev->name);
x25_kill_by_device(dev);
x25_route_device_down(dev);
x25_link_device_down(dev);
break;
+   case NETDEV_PRE_TYPE_CHANGE:
+   pr_debug("X.25: got event NETDEV_PRE_TYPE_CHANGE for 
device: %s\n",
+dev->name);
+   x25_link_device_remove(dev);
+   break;
+   case NETDEV_UNREGISTER:
+   pr_debug("X.25: got event NETDEV_UNREGISTER for device: 
%s\n",
+dev->name);
+   x25_link_device_remove(dev);
+   break;
+   case NETDEV_CHANGE:
+   pr_debug("X.25: got event NETDEV_CHANGE for device: 
%s\n",
+dev->name);
+   nb = x25_get_neigh(dev);
+   if (!nb)
+   break;
+
+   if (!netif_carrier_ok(dev)) {
+   pr_debug("X.25: Carrier lost -> set link state 
down: %s\n",
+dev->name);
+   x25_terminate_link(nb);
+   } else {
+   pr_debug("X.25: Carrier detected: %s\n",
+dev->name);
+   x25_establish_link(nb);
+   }
+   x25_neigh_put(nb);
+   break;
}
}
 
diff --git a/net/x25/x25_link.c b/net/x25/x25_link.c
index fdae054b7dc1..92828a8a4ada 100644
--- a/net/x25/x25_link.c
+++ b/net/x25/x25_link.c
@@ -239,9 +239,17 @@ void x25_link_terminated(struct x25_neigh *nb)
 /*
  * Add a new device.
  */
-void x25_link_device_up(struct net_device *dev)
+void x25_link_device_add(struct net_device *dev)
 {
-   struct x25_neigh *nb = kmalloc(sizeof(*nb), GFP_ATOMIC);
+   struc

Re: violating function pointer signature

2020-11-18 Thread Florian Weimer

* Peter Zijlstra:

> I think that as long as the function is completely empty (it never
> touches any of the arguments) this should work in practise.
>
> That is:
>
>   void tp_nop_func(void) { }
>
> can be used as an argument to any function pointer that has a void
> return. In fact, I already do that, grep for __static_call_nop().

You can pass it as a function parameter, but in general, you cannot
call the function with a different prototype.  Even trivial
differences such as variadic vs non-variadic prototypes matter.

The default Linux calling conventions are all of the cdecl family,
where the caller pops the argument off the stack.  You didn't quote
enough to context to tell whether other calling conventions matter in
your case.

> I'm not sure what the LLVM-CFI crud makes of it, but that's their
> problem.

LTO can cause problems as well, particularly with whole-program
optimization.

[PATCH net-next v3 0/6] net/x25: netdev event handling

---
Changes to v2:
o restructure complete patch-set
o keep netdev event handling in layer3 (X.25)
o add patch to fix lapb_connect_request() for DCE
o add patch to handle carrier loss correctly in lapb
o drop patch for x25_neighbour param handling
  this may need fixes/cleanup and will be resubmitted later.

Changes to v1:
o fix 'subject_prefix' and 'checkpatch' warnings

---

Martin Schiller (6):
  net/x25: handle additional netdev events
  net/lapb: fix lapb_connect_request() for DCE
  net/lapb: handle carrier loss correctly
  net/lapb: fix t1 timer handling for DCE
  net/x25: fix restart request/confirm handling
  net/x25: remove x25_kill_by_device()

 include/net/x25.h |  2 +
 net/lapb/lapb_iface.c | 22 +--
 net/lapb/lapb_timer.c | 11 +-
 net/x25/af_x25.c  | 66 +++
 net/x25/x25_link.c| 90 ---
 net/x25/x25_route.c   |  3 --
 6 files changed, 155 insertions(+), 39 deletions(-)

-- 
2.20.1

[PATCH] pwm: core: Use octal permission

2020-11-18 Thread Soham Biswas

Permission bits are easier readable in octal than with using the symbolic names.

Fixes the following warning generated by checkpatch:

drivers/pwm/core.c:1341: WARNING: Symbolic permissions 'S_IRUGO' are not 
preferred.
Consider using octal permissions '0444'.

+debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
&pwm_debugfs_fops);

Signed-off-by: Soham Biswas 
---
 drivers/pwm/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1f16f5365d3c..a8eff4b3ee36 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -1338,7 +1338,7 @@ DEFINE_SEQ_ATTRIBUTE(pwm_debugfs);
 
 static int __init pwm_debugfs_init(void)
 {
-   debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
+   debugfs_create_file("pwm", S_IFREG | 0444, NULL, NULL,
&pwm_debugfs_fops);
 
return 0;
-- 
2.29.2

[PATCH v5 7/7] ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808

Make some noise with mk808. Enable the hdmi_sound node and
add i2s0 as sound source for hdmi.

Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3066a-mk808.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts 
b/arch/arm/boot/dts/rk3066a-mk808.dts
index eed9e60cf..5fe74c097 100644
--- a/arch/arm/boot/dts/rk3066a-mk808.dts
+++ b/arch/arm/boot/dts/rk3066a-mk808.dts
@@ -116,6 +116,14 @@
};
 };
 
+&hdmi_sound {
+   status = "okay";
+};
+
+&i2s0 {
+   status = "okay";
+};
+
 &mmc0 {
bus-width = <4>;
cap-mmc-highspeed;
-- 
2.11.0

[PATCH v5 6/7] ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi

Add hdmi-sound node to rk3066a.dtsi, so that it
can be reused by boards with HDMI support.

Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3066a.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 67fcb0dc9..f91ce3054 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -49,6 +49,22 @@
ports = <&vop0_out>, <&vop1_out>;
};
 
+   hdmi_sound: hdmi-sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "HDMI";
+   simple-audio-card,format = "i2s";
+   simple-audio-card,mclk-fs = <256>;
+   status = "disabled";
+
+   simple-audio-card,codec {
+   sound-dai = <&hdmi>;
+   };
+
+   simple-audio-card,cpu {
+   sound-dai = <&i2s0>;
+   };
+   };
+
sram: sram@1008 {
compatible = "mmio-sram";
reg = <0x1008 0x1>;
-- 
2.11.0

[PATCH v5 3/7] dt-bindings: display: add #sound-dai-cells property to rockchip rk3066 hdmi

'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property.
Add it to rockchip,rk3066-hdmi.yaml to document that the
rk3066 HDMI TX also can be used to transmit some audio.

Signed-off-by: Johan Jonker 
---
 .../devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml| 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
index 4110d003c..585a8d3b9 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
+++ 
b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml
@@ -42,6 +42,9 @@ properties:
 description:
   This soc uses GRF regs to switch the HDMI TX input between vop0 and vop1.
 
+  "#sound-dai-cells":
+const: 0
+
   ports:
 type: object
 
@@ -101,6 +104,7 @@ examples:
   pinctrl-names = "default";
   power-domains = <&power RK3066_PD_VIO>;
   rockchip,grf = <&grf>;
+  #sound-dai-cells = <0>;
 
   ports {
 #address-cells = <1>;
-- 
2.11.0

[PATCH v5 5/7] ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node

'#sound-dai-cells' is required to properly interpret
the list of DAI specified in the 'sound-dai' property,
so add them to the 'hdmi' node for 'rk3066a.dtsi'.

Signed-off-by: Johan Jonker 
---
 arch/arm/boot/dts/rk3066a.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 252750c97..67fcb0dc9 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -124,6 +124,7 @@
pinctrl-0 = <&hdmii2c_xfer>, <&hdmi_hpd>;
power-domains = <&power RK3066_PD_VIO>;
rockchip,grf = <&grf>;
+   #sound-dai-cells = <0>;
status = "disabled";
 
ports {
-- 
2.11.0

[PATCH v5 4/7] drm: rockchip: add sound support to rk3066 hdmi driver

From: Zheng Yang 

Add sound support to the rk3066 HDMI driver.

The I2S input of the HDMI TX allows transmission of
DVD-Audio and decoded Dolby Digital
to A/V Receivers and high-end displays.
The interface supports 2 to 8 channels audio up to 192 kHz.
The HDMI TX supports variable word length of
16bits to 32bits for I2S audio inputs.(This driver 24bit max)
There are three I2S input modes supported.(This driver HDMI_I2S only)
On RK3066/PX2 the HDMI TX audio source is connected to I2S_8CH.

Signed-off-by: Zheng Yang 
Signed-off-by: Johan Jonker 
---
 drivers/gpu/drm/rockchip/Kconfig   |   2 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 275 -
 2 files changed, 276 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 310aa1546..4c20445dc 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -11,6 +11,8 @@ config DRM_ROCKCHIP
select DRM_DW_MIPI_DSI if ROCKCHIP_DW_MIPI_DSI
select DRM_RGB if ROCKCHIP_RGB
select SND_SOC_HDMI_CODEC if ROCKCHIP_CDN_DP && SND_SOC
+   select SND_SOC_HDMI_CODEC if ROCKCHIP_RK3066_HDMI && SND_SOC
+   select SND_SOC_ROCKCHIP_I2S if ROCKCHIP_RK3066_HDMI && SND_SOC
help
  Choose this option if you have a Rockchip soc chipset.
  This driver provides kernel mode setting and buffer
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c 
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 1c546c3a8..243e4077f 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 #include "rk3066_hdmi.h"
 
 #include "rockchip_drm_drv.h"
@@ -20,9 +22,16 @@
 
 #define DEFAULT_PLLA_RATE 3000
 
+struct audio_info {
+   int sample_rate;
+   int channels;
+   int sample_width;
+};
+
 struct hdmi_data_info {
int vic; /* The CEA Video ID (VIC) of the current drm display mode. */
bool sink_is_hdmi;
+   bool sink_has_audio;
unsigned int enc_out_format;
unsigned int colorimetry;
 };
@@ -54,12 +63,19 @@ struct rk3066_hdmi {
 
unsigned int tmdsclk;
 
+   struct platform_device *audio_pdev;
+   bool audio_enable;
+
struct hdmi_data_info hdmi_data;
+   struct audio_info audio;
struct drm_display_mode previous_mode;
 };
 
 #define to_rk3066_hdmi(x) container_of(x, struct rk3066_hdmi, x)
 
+static int
+rk3066_hdmi_config_audio(struct rk3066_hdmi *hdmi, struct audio_info *audio);
+
 static inline u8 hdmi_readb(struct rk3066_hdmi *hdmi, u16 offset)
 {
return readl_relaxed(hdmi->regs + offset);
@@ -205,6 +221,23 @@ static int rk3066_hdmi_config_avi(struct rk3066_hdmi *hdmi,
HDMI_INFOFRAME_AVI, 0, 0, 0);
 }
 
+static int rk3066_hdmi_config_aai(struct rk3066_hdmi *hdmi,
+ struct audio_info *audio)
+{
+   union hdmi_infoframe frame;
+   int rc;
+
+   rc = hdmi_audio_infoframe_init(&frame.audio);
+
+   frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
+   frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
+   frame.audio.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
+   frame.audio.channels = hdmi->audio.channels;
+
+   return rk3066_hdmi_upload_frame(hdmi, rc, &frame,
+   HDMI_INFOFRAME_AAI, 0, 0, 0);
+}
+
 static int rk3066_hdmi_config_video_timing(struct rk3066_hdmi *hdmi,
   struct drm_display_mode *mode)
 {
@@ -353,6 +386,7 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK,
  HDMI_VIDEO_MODE_HDMI);
rk3066_hdmi_config_avi(hdmi, mode);
+   rk3066_hdmi_config_audio(hdmi, &hdmi->audio);
} else {
hdmi_modb(hdmi, HDMI_HDCP_CTRL, HDMI_VIDEO_MODE_MASK, 0);
}
@@ -369,9 +403,20 @@ static int rk3066_hdmi_setup(struct rk3066_hdmi *hdmi,
 */
rk3066_hdmi_i2c_init(hdmi);
 
-   /* Unmute video output. */
+   /* Unmute video and audio output. */
hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
  HDMI_VIDEO_AUDIO_DISABLE_MASK, HDMI_AUDIO_DISABLE);
+   if (hdmi->audio_enable) {
+   hdmi_modb(hdmi, HDMI_VIDEO_CTRL2, HDMI_AUDIO_DISABLE, 0);
+   /* Reset audio capture logic. */
+   hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK,
+ HDMI_AUDIO_CP_LOGIC_RESET);
+   usleep_range(900, 1000);
+   hdmi_modb(hdmi, HDMI_VIDEO_CTRL2,
+ HDMI_AUDIO_CP_LOGIC_RESET_MASK, 0);
+   }
+
return 0;
 }
 
@@ -473,9 +518,13 @@ static int rk3066_hdmi_connector_get_modes(struct 
drm_connector *connector)
edid = drm_get_edid(connector, hdmi->ddc);

[PATCH v5 2/7] clk: rockchip: fix i2s gate bits on rk3066 and rk3188

The Rockchip PX2/RK3066 uses these bits in CRU_CLKGATE7_CON:

hclk_i2s_8ch_gate_en  bit 4 (dtsi: i2s0)
hclk_i2s0_2ch_gate_en bit 2 (dtsi: i2s1)
hclk_i2s1_2ch_gate_en bit 3 (dtsi: i2s2)

The Rockchip PX3/RK3188 uses this bit in CRU_CLKGATE7_CON:

hclk_i2s_2ch_gate_en  bit 2 (dtsi: i2s0)

The bits got somehow mixed up in the clk-rk3188.c file.
The labels in the dtsi files are not suppose to change.
The sclk and hclk names should match for
"trace_event=clk_disable,clk_enable",
so remove GATE HCLK_I2S0 from the common clock tree and
fix the bits in the rk3066 and rk3188 clock tree.

Signed-off-by: Johan Jonker 
---
Changed v3:
  reword
---
 drivers/clk/rockchip/clk-rk3188.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index db8c58813..0b76ad34d 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -449,7 +449,6 @@ static struct rockchip_clk_branch common_clk_branches[] 
__initdata = {
 
/* hclk_cpu gates */
GATE(HCLK_ROM, "hclk_rom", "hclk_cpu", 0, RK2928_CLKGATE_CON(5), 6, 
GFLAGS),
-   GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2, 
GFLAGS),
GATE(HCLK_SPDIF, "hclk_spdif", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 1, 
GFLAGS),
GATE(0, "hclk_cpubus", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 8, GFLAGS),
/* hclk_ahb2apb is part of a clk branch */
@@ -634,8 +633,9 @@ static struct rockchip_clk_branch rk3066a_clk_branches[] 
__initdata = {
RK2928_CLKGATE_CON(0), 12, GFLAGS,
&rk3066a_i2s2_fracmux),
 
-   GATE(HCLK_I2S1, "hclk_i2s1", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 3, 
GFLAGS),
-   GATE(HCLK_I2S2, "hclk_i2s2", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 4, 
GFLAGS),
+   GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 4, 
GFLAGS),
+   GATE(HCLK_I2S1, "hclk_i2s1", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2, 
GFLAGS),
+   GATE(HCLK_I2S2, "hclk_i2s2", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 3, 
GFLAGS),
GATE(HCLK_CIF1, "hclk_cif1", "hclk_cpu", 0, RK2928_CLKGATE_CON(6), 6, 
GFLAGS),
GATE(HCLK_HDMI, "hclk_hdmi", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 14, 
GFLAGS),
 
@@ -728,6 +728,7 @@ static struct rockchip_clk_branch rk3188_clk_branches[] 
__initdata = {
RK2928_CLKGATE_CON(0), 10, GFLAGS,
&rk3188_i2s0_fracmux),
 
+   GATE(HCLK_I2S0, "hclk_i2s0", "hclk_cpu", 0, RK2928_CLKGATE_CON(7), 2, 
GFLAGS),
GATE(0, "hclk_imem0", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 14, GFLAGS),
GATE(0, "hclk_imem1", "hclk_cpu", 0, RK2928_CLKGATE_CON(4), 15, GFLAGS),
 
-- 
2.11.0

[PATCH v5 0/7] Enable rk3066a HDMI sound

First fix some legacy things in clk-rk3188.c that was never updated,
because probably nobody used rk3066a I2S before in the mainline kernel.
Update the rk3066a HDMI documents with a #sound-dai-cells property.
Include the code for sound in the HDMI driver.
Add a simple-sound-card compatible node to rk3066a.dtsi,
because I2S0 and HDMI TX are connected internally.
And as last enable rk3066a HDMI sound in the rk3066a-mk808.dts file.

Changed v5:
  removed unused variable
  fill frame structure

Johan Jonker (6):
  clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and
uart clocks
  clk: rockchip: fix i2s gate bits on rk3066 and rk3188
  dt-bindings: display: add #sound-dai-cells property to rockchip rk3066
hdmi
  ARM: dts: rockchip: rk3066a: add #sound-dai-cells to hdmi node
  ARM: dts: rockchip: add hdmi-sound node to rk3066a.dtsi
  ARM: dts: rockchip: enable hdmi_sound and i2s0 for rk3066a-mk808

Zheng Yang (1):
  drm: rockchip: add sound support to rk3066 hdmi driver

 .../display/rockchip/rockchip,rk3066-hdmi.yaml |   4 +
 arch/arm/boot/dts/rk3066a-mk808.dts|   8 +
 arch/arm/boot/dts/rk3066a.dtsi |  17 ++
 drivers/clk/rockchip/clk-rk3188.c  |  35 +--
 drivers/gpu/drm/rockchip/Kconfig   |   2 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c | 275 -
 6 files changed, 323 insertions(+), 18 deletions(-)

--
2.11.0

[PATCH v5 1/7] clk: rockchip: add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks

Add CLK_SET_RATE_PARENT to sclk for rk3066a i2s and uart clocks,
so that the parent COMPOSITE_FRACMUX and COMPOSITE_NOMUX
also update.

Signed-off-by: Johan Jonker 
---
 drivers/clk/rockchip/clk-rk3188.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3188.c 
b/drivers/clk/rockchip/clk-rk3188.c
index 730020fcc..db8c58813 100644
--- a/drivers/clk/rockchip/clk-rk3188.c
+++ b/drivers/clk/rockchip/clk-rk3188.c
@@ -255,19 +255,19 @@ static struct rockchip_clk_branch common_spdif_fracmux 
__initdata =
RK2928_CLKSEL_CON(5), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch common_uart0_fracmux __initdata =
-   MUX(SCLK_UART0, "sclk_uart0", mux_sclk_uart0_p, 0,
+   MUX(SCLK_UART0, "sclk_uart0", mux_sclk_uart0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(13), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch common_uart1_fracmux __initdata =
-   MUX(SCLK_UART1, "sclk_uart1", mux_sclk_uart1_p, 0,
+   MUX(SCLK_UART1, "sclk_uart1", mux_sclk_uart1_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(14), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch common_uart2_fracmux __initdata =
-   MUX(SCLK_UART2, "sclk_uart2", mux_sclk_uart2_p, 0,
+   MUX(SCLK_UART2, "sclk_uart2", mux_sclk_uart2_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(15), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch common_uart3_fracmux __initdata =
-   MUX(SCLK_UART3, "sclk_uart3", mux_sclk_uart3_p, 0,
+   MUX(SCLK_UART3, "sclk_uart3", mux_sclk_uart3_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(16), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch common_clk_branches[] __initdata = {
@@ -408,28 +408,28 @@ static struct rockchip_clk_branch common_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "uart0_pre", "uart_src", 0,
RK2928_CLKSEL_CON(13), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 8, GFLAGS),
-   COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_pre", 0,
+   COMPOSITE_FRACMUX(0, "uart0_frac", "uart0_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(17), 0,
RK2928_CLKGATE_CON(1), 9, GFLAGS,
&common_uart0_fracmux),
COMPOSITE_NOMUX(0, "uart1_pre", "uart_src", 0,
RK2928_CLKSEL_CON(14), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 10, GFLAGS),
-   COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_pre", 0,
+   COMPOSITE_FRACMUX(0, "uart1_frac", "uart1_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(18), 0,
RK2928_CLKGATE_CON(1), 11, GFLAGS,
&common_uart1_fracmux),
COMPOSITE_NOMUX(0, "uart2_pre", "uart_src", 0,
RK2928_CLKSEL_CON(15), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 12, GFLAGS),
-   COMPOSITE_FRACMUX(0, "uart2_frac", "uart2_pre", 0,
+   COMPOSITE_FRACMUX(0, "uart2_frac", "uart2_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(19), 0,
RK2928_CLKGATE_CON(1), 13, GFLAGS,
&common_uart2_fracmux),
COMPOSITE_NOMUX(0, "uart3_pre", "uart_src", 0,
RK2928_CLKSEL_CON(16), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(1), 14, GFLAGS),
-   COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_pre", 0,
+   COMPOSITE_FRACMUX(0, "uart3_frac", "uart3_pre", CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(20), 0,
RK2928_CLKGATE_CON(1), 15, GFLAGS,
&common_uart3_fracmux),
@@ -543,15 +543,15 @@ static struct clk_div_table div_aclk_cpu_t[] = {
 };
 
 static struct rockchip_clk_branch rk3066a_i2s0_fracmux __initdata =
-   MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, 0,
+   MUX(SCLK_I2S0, "sclk_i2s0", mux_sclk_i2s0_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(2), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch rk3066a_i2s1_fracmux __initdata =
-   MUX(SCLK_I2S1, "sclk_i2s1", mux_sclk_i2s1_p, 0,
+   MUX(SCLK_I2S1, "sclk_i2s1", mux_sclk_i2s1_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(3), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch rk3066a_i2s2_fracmux __initdata =
-   MUX(SCLK_I2S2, "sclk_i2s2", mux_sclk_i2s2_p, 0,
+   MUX(SCLK_I2S2, "sclk_i2s2", mux_sclk_i2s2_p, CLK_SET_RATE_PARENT,
RK2928_CLKSEL_CON(4), 8, 2, MFLAGS);
 
 static struct rockchip_clk_branch rk3066a_clk_branches[] __initdata = {
@@ -615,21 +615,21 @@ static struct rockchip_clk_branch rk3066a_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "i2s0_pre", "i2s_src", 0,
RK2928_CLKSEL_CON(2), 0, 7, DFLAGS,
RK2928_CLKGATE_CON(0), 7, GFLAGS),
-   COMPOSITE_FRACMUX(0, "i2s0_fra

hi

2020-11-18 Thread Jessica Vail

Hi dear,

I'm Jessica Vail, from the United States,please i wish to have a
communication with you.

I wait for your answer.

Jessica Vail.

Re: [PATCH v3] lockdep: Allow tuning tracing capacity constants.

2020-11-18 Thread Tetsuo Handa

Peter, do you have a plan to make this problem actionable?

On 2020/10/18 22:02, Tetsuo Handa wrote:
> Peter, what do you think? Can we apply this patch?
> 
> A potential for-now workaround for syzkaller would be to allow syzkaller
> not to encounter the BUG: message (by masking BUG: message on the kernel
> side) when hitting these limits, for continue testing until the kernel
> crashes (due to other bugs like UAF) would be to some degree useful.
> 
> On 2020/10/10 21:58, Tetsuo Handa wrote:
>> Since syzkaller continues various test cases until the kernel crashes,
>> syzkaller tends to examine more locking dependencies than normal systems.
>> As a result, syzbot is reporting that the fuzz testing was terminated
>> due to hitting upper limits lockdep can track [1] [2] [3].
>>
>> Peter Zijlstra does not want to allow tuning these limits via kernel
>> config options, for such change discourages thinking. But currently we
>> are not actionable, for lockdep does not report the culprit for hitting
>> these limits [4].
>>
>> Therefore, I propose this patch again, with a caveat that this patch is
>> expected to be reverted after lockdep becomes capable of reporting the
>> culprit, for I consider that "postpone fixing lock related problems in
>> existing code" is less painful than "not detecting lock related problems
>> introduced by new patches".
>>
>> [1] 
>> https://syzkaller.appspot.com/bug?id=3d97ba93fb3566000c1c59691ea427370d33ea1b
>> [2] 
>> https://syzkaller.appspot.com/bug?id=381cb436fe60dc03d7fd2a092b46d7f09542a72a
>> [3] 
>> https://syzkaller.appspot.com/bug?id=a588183ac34c1437fc0785e8f220e88282e5a29f
>> [4] 
>> https://lkml.kernel.org/r/CACT4Y+agTiEF-1i9LbAgp-q_02oYF0kAPZGAAJ==-wx2xh7...@mail.gmail.com
>>
>> Reported-by: syzbot 
>> Reported-by: syzbot 
>> Reported-by: syzbot 
>> Signed-off-by: Tetsuo Handa 
>> Acked-by: Dmitry Vyukov 
>> ---
>>  kernel/locking/lockdep.c   |  2 +-
>>  kernel/locking/lockdep_internals.h |  8 +++---
>>  lib/Kconfig.debug  | 40 ++
>>  3 files changed, 45 insertions(+), 5 deletions(-)

Re: [PATCH net-next v2 5/6] net/lapb: support netdev events

On 2020-11-18 14:46, Xie He wrote:

On Wed, Nov 18, 2020 at 5:03 AM Xie He  wrote:

On Wed, Nov 18, 2020 at 12:49 AM Martin Schiller  
wrote:

>
> I also have a patch here that implements an "on demand" link feature,
> which we used for ISDN dialing connections.
> As ISDN is de facto dead, this is not relevant anymore. But if we want
> such kind of feature, I think we need to stay with the method to control
> L2 link state from L3.

I see. Hmm...

I guess for ISDN, the current code (before this patch series) is the
best. We only establish the connection when L3 has packets to send.

Can we do this? We let L2 handle all device-up / device-down /
carrier-up / carrier-down events. And when L3 has some packets to send
but it still finds the L2 link is not up, it will then instruct L2 to
connect.

This way we may be able to both keep the logic simple and still keep
L3 compatible with ISDN.

Another solution might be letting ISDN automatically connect when it
receives the first packet from L3. This way we can still free L3 from
all handlings of L2 connections.

ISDN is not important now. Also the I4L subsystem has been removed.

I have now completely reworked the patch-set and it is now much tidier.
For now I left the event handling completely in X.25 (L3).

I will now send the whole thing as v3 and we can discuss it further.

Re: [PATCH][next] drm/selftests/test-drm_dp_mst_helper: fix memory leak allocated to 'out'

2020-11-18 Thread Lee Jones

On Wed, 18 Nov 2020, Colin King wrote:

> From: Colin Ian King 
> 
> Currently when txmsg fails to allocate then there is a leak on 'out'. Fix
> this by setting result to false and exiting via the clean up exit path.
> Note since txmsg is NULL at this point, the kfree of txmsg is a no-op.
> 
> Addresses-Coverity: ("Resource leak")
> Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move 
> 'sideband_msg_req_encode_decode' onto the heap")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

This is fixed in my local branch.

Looks like the wrong version of the patch was sent/applied.

Either way, thanks for the fix Colin.

Reviewed-by: Lee Jones 

> diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c 
> b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> index 6b4759ed6bfd..dbac073ed385 100644
> --- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> +++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
> @@ -131,8 +131,10 @@ sideband_msg_req_encode_decode(struct 
> drm_dp_sideband_msg_req_body *in)
>   return false;
>  
>   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> - if (!txmsg)
> - return false;
> + if (!txmsg) {
> + result = false;
> + goto out;
> + }
>  
>   drm_dp_encode_sideband_req(in, txmsg);
>   ret = drm_dp_decode_sideband_req(txmsg, out);

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI interrupt link

2020-11-18 Thread Rafael J. Wysocki

On Wed, Nov 18, 2020 at 2:46 PM Ard Biesheuvel  wrote:
>
> On Tue, 17 Nov 2020 at 19:57, Bjorn Helgaas  wrote:
> >
> > Nit: please don't just make up random styles for the subject.  Run
> > "git log --oneline" on the file and/or the directory and try to follow
> > the existing convention.  Using random styles adds noise to the
> > system.
> >
> > On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
> > > Some PCIe designs require software to do extra acknowledgements for
> > > legacy INTx interrupts. If the driver is written only for device tree,
> > > things are simple. In that case, a new driver can be written under
> > > driver/pci/controller/ with a DT node of PCIe host written like:
> > >
> > >   pcie {
> > > ...
> > > interrupt-map = <0 0 0  1  &pcie_intc 0>,
> > > <0 0 0  2  &pcie_intc 1>,
> > > <0 0 0  3  &pcie_intc 2>,
> > > <0 0 0  4  &pcie_intc 3>;
> > >
> > > pcie_intc: legacy-interrupt-controller {
> > >   interrupt-controller;
> > >   #interrupt-cells = <1>;
> > >   interrupt-parent = <&gic>;
> > >   interrupts = <0 226 4>;
> > > };
> > >   };
> > >
> > > Similar designs can be found on Aardvark, MediaTek Gen2 and Socionext
> > > UniPhier PCIe controller at the moment. Essentially, those designs are
> > > supported by inserting an extra interrupt controller between PCIe host
> > > and GIC and parse the topology in a DT-based PCI controller driver.
> >
> > If I understand correctly, we previously ignored the Resource Source
> > field of an Extended Interrupt Descriptor in the _PRS method of
> > PNP0C0F PCI Interrupt Link devices, and this patch adds support for
> > it.
> >
> > If that's true, this has nothing to do with DT, other than DT being
> > another way to describe the same topology, and the above details
> > really aren't relevant to this patch.
> >
> > > As we turn to ACPI, All the PCIe hosts are described the same ID of
> > > "PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
> > > to make this kind of PCI INTx work under ACPI.
> >
> > s/All the PCIe/all the PCIe/
> >
> > But this paragraph should probably just go away in favor of something
> > about implementing Resource Source support.
> >
> > > Therefore, we introduce an stacked IRQ domain support to PCI interrupt
> > > link for ACPI. With this support, we can populate the ResourceSource
> > > to refer to a device object that describes an interrupt controller.
> > > That would allow us to refer to a dedicated driver which implements
> > > the logic needed to manage the interrupt state. With this patch,
> > > those PCI interrupt links can be supported by describing the INTx
> > > in ACPI table as the following example:
> >
> > "Stacked IRQ domain" sounds like a detail of how you're implementing
> > support for the Resource Source field for PCI Interrupt Links.
> >
> > I don't know what the dedicated driver refers to.  This *should* be
> > all generic code the follows the ACPI spec (which is pretty sketchy in
> > this area).  But I assume that there's no special driver needed for
> > devices like \SB.IXIU, and the logic associated with the interrupt
> > controller is in the AML associated with IXIU.  It would probably be
> > useful to mention the relevant methods in the IXIU methods in the
> > example below.
> >
>
> As I understand it, the intent is to provide a driver for \SB.IXIU
> that acknowledges the legacy INTx interrupts in a SoC specific way,
> and I don't see how AML could be involved here.
>
> That also explains why the routines are exported to modules - the IXIU
> driver could be modularized.

OK, but every new symbol export requires an in-the-tree user or the
patch is basically not applicable.

[PATCH] habanalabs: print CS type when it is stuck

2020-11-18 Thread Oded Gabbay

We have several types of command submissions and the user wants to know
which type of command submission has not finished in time when that
event occurs. This is very helpful for debug.

Signed-off-by: Oded Gabbay 
---
 .../habanalabs/common/command_submission.c| 28 +--
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/habanalabs/common/command_submission.c 
b/drivers/misc/habanalabs/common/command_submission.c
index 516cbaacc03e..6ca77abf7f8a 100644
--- a/drivers/misc/habanalabs/common/command_submission.c
+++ b/drivers/misc/habanalabs/common/command_submission.c
@@ -418,9 +418,31 @@ static void cs_timedout(struct work_struct *work)
 
hdev = cs->ctx->hdev;
 
-   dev_err(hdev->dev,
-   "Command submission %llu has not finished in time!\n",
-   cs->sequence);
+   switch (cs->type) {
+   case CS_TYPE_SIGNAL:
+   dev_err(hdev->dev,
+   "Signal command submission %llu has not finished in 
time!\n",
+   cs->sequence);
+   break;
+
+   case CS_TYPE_WAIT:
+   dev_err(hdev->dev,
+   "Wait command submission %llu has not finished in 
time!\n",
+   cs->sequence);
+   break;
+
+   case CS_TYPE_COLLECTIVE_WAIT:
+   dev_err(hdev->dev,
+   "Collective Wait command submission %llu has not 
finished in time!\n",
+   cs->sequence);
+   break;
+
+   default:
+   dev_err(hdev->dev,
+   "Command submission %llu has not finished in time!\n",
+   cs->sequence);
+   break;
+   }
 
cs_put(cs);
 
-- 
2.17.1

[PATCH] habanalabs: mmu map wrapper for sizes larger than a page

2020-11-18 Thread Oded Gabbay

From: Ofir Bitton 

We introduce a new wrapper which allows us to mmu map any size
to any host va_range available. In addition we remove duplicated
code from various places in driver and using this new wrapper
instead.
This wrapper supports mapping only contiguous physical
memory blocks and will be used for mappings that are done to the
driver ASID.

Signed-off-by: Ofir Bitton 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 .../misc/habanalabs/common/command_buffer.c   |  10 +-
 drivers/misc/habanalabs/common/habanalabs.h   |   7 +-
 drivers/misc/habanalabs/common/memory.c   |   6 +-
 drivers/misc/habanalabs/common/mmu.c  | 112 +-
 drivers/misc/habanalabs/gaudi/gaudi.c |  60 ++
 drivers/misc/habanalabs/goya/goya.c   |  26 ++--
 6 files changed, 144 insertions(+), 77 deletions(-)

diff --git a/drivers/misc/habanalabs/common/command_buffer.c 
b/drivers/misc/habanalabs/common/command_buffer.c
index 0c482358f350..2856bb3423ee 100644
--- a/drivers/misc/habanalabs/common/command_buffer.c
+++ b/drivers/misc/habanalabs/common/command_buffer.c
@@ -67,9 +67,9 @@ static int cb_map_mem(struct hl_ctx *ctx, struct hl_cb *cb)
bus_addr = cb->bus_address;
offset = 0;
list_for_each_entry(va_block, &cb->va_block_list, node) {
-   rc = hl_mmu_map(ctx, va_block->start, bus_addr, va_block->size,
-   list_is_last(&va_block->node,
-   &cb->va_block_list));
+   rc = hl_mmu_map_page(ctx, va_block->start, bus_addr,
+   va_block->size, list_is_last(&va_block->node,
+   &cb->va_block_list));
if (rc) {
dev_err(hdev->dev, "Failed to map VA %#llx to CB\n",
va_block->start);
@@ -92,7 +92,7 @@ static int cb_map_mem(struct hl_ctx *ctx, struct hl_cb *cb)
list_for_each_entry(va_block, &cb->va_block_list, node) {
if (offset <= 0)
break;
-   hl_mmu_unmap(ctx, va_block->start, va_block->size,
+   hl_mmu_unmap_page(ctx, va_block->start, va_block->size,
offset <= va_block->size);
offset -= va_block->size;
}
@@ -119,7 +119,7 @@ static void cb_unmap_mem(struct hl_ctx *ctx, struct hl_cb 
*cb)
mutex_lock(&ctx->mmu_lock);
 
list_for_each_entry(va_block, &cb->va_block_list, node)
-   if (hl_mmu_unmap(ctx, va_block->start, va_block->size,
+   if (hl_mmu_unmap_page(ctx, va_block->start, va_block->size,
list_is_last(&va_block->node,
&cb->va_block_list)))
dev_warn_ratelimited(hdev->dev,
diff --git a/drivers/misc/habanalabs/common/habanalabs.h 
b/drivers/misc/habanalabs/common/habanalabs.h
index 43aa8cbd8969..e1db8301ecbd 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -2162,10 +2162,13 @@ int hl_mmu_init(struct hl_device *hdev);
 void hl_mmu_fini(struct hl_device *hdev);
 int hl_mmu_ctx_init(struct hl_ctx *ctx);
 void hl_mmu_ctx_fini(struct hl_ctx *ctx);
-int hl_mmu_map(struct hl_ctx *ctx, u64 virt_addr, u64 phys_addr,
+int hl_mmu_map_page(struct hl_ctx *ctx, u64 virt_addr, u64 phys_addr,
u32 page_size, bool flush_pte);
-int hl_mmu_unmap(struct hl_ctx *ctx, u64 virt_addr, u32 page_size,
+int hl_mmu_unmap_page(struct hl_ctx *ctx, u64 virt_addr, u32 page_size,
bool flush_pte);
+int hl_mmu_map_contiguous(struct hl_ctx *ctx, u64 virt_addr,
+   u64 phys_addr, u32 size);
+int hl_mmu_unmap_contiguous(struct hl_ctx *ctx, u64 virt_addr, u32 size);
 void hl_mmu_swap_out(struct hl_ctx *ctx);
 void hl_mmu_swap_in(struct hl_ctx *ctx);
 int hl_mmu_if_set_funcs(struct hl_device *hdev);
diff --git a/drivers/misc/habanalabs/common/memory.c 
b/drivers/misc/habanalabs/common/memory.c
index 351c9927151f..744275dd6410 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -843,7 +843,7 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
for (i = 0 ; i < phys_pg_pack->npages ; i++) {
paddr = phys_pg_pack->pages[i];
 
-   rc = hl_mmu_map(ctx, next_vaddr, paddr, page_size,
+   rc = hl_mmu_map_page(ctx, next_vaddr, paddr, page_size,
(i + 1) == phys_pg_pack->npages);
if (rc) {
dev_err(hdev->dev,
@@ -862,7 +862,7 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
 err:
next_vaddr = vaddr;
for (i = 0 ; i < mapped_pg_cnt ; i++) {
-   if (hl_mmu_unmap(ctx, next_vaddr, page_size,
+   if (hl_mmu_unmap_page(ctx, next_vaddr, page_size,

[PATCH] habanalabs: fetch pll frequency from firmware

2020-11-18 Thread Oded Gabbay

From: Alon Mizrahi 

Once firmware security is enabled, driver must fetch pll frequencies
through the firmware message interface instead of reading the registers
directly.

Signed-off-by: Alon Mizrahi 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/common/firmware_if.c  |  24 ++--
 drivers/misc/habanalabs/common/habanalabs.h   |   9 +-
 .../misc/habanalabs/common/habanalabs_ioctl.c |  22 +++
 drivers/misc/habanalabs/gaudi/gaudi.c | 135 --
 drivers/misc/habanalabs/gaudi/gaudiP.h|   8 ++
 drivers/misc/habanalabs/goya/goya.c   |   2 +-
 .../misc/habanalabs/include/common/cpucp_if.h |  40 +-
 .../habanalabs/include/common/hl_boot_if.h|   4 +
 .../include/gaudi/asic_reg/gaudi_regs.h   |  14 +-
 .../gaudi/asic_reg/psoc_hbm_pll_regs.h| 114 ---
 .../gaudi/asic_reg/psoc_pci_pll_regs.h| 114 ---
 include/uapi/misc/habanalabs.h|   9 ++
 12 files changed, 199 insertions(+), 296 deletions(-)
 delete mode 100644 
drivers/misc/habanalabs/include/gaudi/asic_reg/psoc_hbm_pll_regs.h
 delete mode 100644 
drivers/misc/habanalabs/include/gaudi/asic_reg/psoc_pci_pll_regs.h

diff --git a/drivers/misc/habanalabs/common/firmware_if.c 
b/drivers/misc/habanalabs/common/firmware_if.c
index 8f70d0bbe5e1..c4a8d6ca34bb 100644
--- a/drivers/misc/habanalabs/common/firmware_if.c
+++ b/drivers/misc/habanalabs/common/firmware_if.c
@@ -279,7 +279,8 @@ int hl_fw_send_heartbeat(struct hl_device *hdev)
return rc;
 }
 
-int hl_fw_cpucp_info_get(struct hl_device *hdev)
+int hl_fw_cpucp_info_get(struct hl_device *hdev,
+   u32 cpu_security_boot_status_reg)
 {
struct asic_fixed_properties *prop = &hdev->asic_prop;
struct cpucp_packet pkt = {};
@@ -324,6 +325,11 @@ int hl_fw_cpucp_info_get(struct hl_device *hdev)
goto out;
}
 
+   /* Read FW application security bits again */
+   if (hdev->asic_prop.fw_security_status_valid)
+   hdev->asic_prop.fw_app_security_map =
+   RREG32(cpu_security_boot_status_reg);
+
 out:
hdev->asic_funcs->cpu_accessible_dma_pool_free(hdev,
sizeof(struct cpucp_info), cpucp_info_cpu_addr);
@@ -446,10 +452,8 @@ int hl_fw_cpucp_total_energy_get(struct hl_device *hdev, 
u64 *total_energy)
return rc;
 }
 
-int hl_fw_cpucp_pll_info_get(struct hl_device *hdev,
-   enum cpucp_pll_type_attributes pll_type,
-   enum cpucp_pll_reg_attributes pll_reg,
-   u32 *pll_info)
+int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, u16 pll_index,
+   u16 *pll_freq_arr)
 {
struct cpucp_packet pkt;
u64 result;
@@ -457,17 +461,19 @@ int hl_fw_cpucp_pll_info_get(struct hl_device *hdev,
 
memset(&pkt, 0, sizeof(pkt));
 
-   pkt.ctl = cpu_to_le32(CPUCP_PACKET_PLL_REG_GET <<
+   pkt.ctl = cpu_to_le32(CPUCP_PACKET_PLL_INFO_GET <<
CPUCP_PKT_CTL_OPCODE_SHIFT);
-   pkt.pll_type = __cpu_to_le16(pll_type);
-   pkt.pll_reg = __cpu_to_le16(pll_reg);
+   pkt.pll_type = __cpu_to_le16(pll_index);
 
rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) &pkt, sizeof(pkt),
HL_CPUCP_INFO_TIMEOUT_USEC, &result);
if (rc)
dev_err(hdev->dev, "Failed to read PLL info, error %d\n", rc);
 
-   *pll_info = (u32) result;
+   pll_freq_arr[0] = FIELD_GET(CPUCP_PKT_RES_PLL_OUT0_MASK, result);
+   pll_freq_arr[1] = FIELD_GET(CPUCP_PKT_RES_PLL_OUT1_MASK, result);
+   pll_freq_arr[2] = FIELD_GET(CPUCP_PKT_RES_PLL_OUT2_MASK, result);
+   pll_freq_arr[3] = FIELD_GET(CPUCP_PKT_RES_PLL_OUT3_MASK, result);
 
return rc;
 }
diff --git a/drivers/misc/habanalabs/common/habanalabs.h 
b/drivers/misc/habanalabs/common/habanalabs.h
index e1db8301ecbd..9c9c8b24c47a 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -2191,16 +2191,15 @@ void *hl_fw_cpu_accessible_dma_pool_alloc(struct 
hl_device *hdev, size_t size,
 void hl_fw_cpu_accessible_dma_pool_free(struct hl_device *hdev, size_t size,
void *vaddr);
 int hl_fw_send_heartbeat(struct hl_device *hdev);
-int hl_fw_cpucp_info_get(struct hl_device *hdev);
+int hl_fw_cpucp_info_get(struct hl_device *hdev,
+   u32 cpu_security_boot_status_reg);
 int hl_fw_get_eeprom_data(struct hl_device *hdev, void *data, size_t max_size);
 int hl_fw_cpucp_pci_counters_get(struct hl_device *hdev,
struct hl_info_pci_counters *counters);
 int hl_fw_cpucp_total_energy_get(struct hl_device *hdev,
u64 *total_energy);
-int hl_fw_cpucp_pll_info_get(struct hl_device *hdev,
-   enum cpucp_pll_type_attributes pll_type,
-   enum cpucp_pll_reg_attributes pll_reg,
-   u32 *pll_info);
+in

Re: [PATCH v2] pwm: core: Use octal permission

2020-11-18 Thread Lee Jones

On Wed, 18 Nov 2020, Soham Biswas wrote:

> Sure will do that. Sorry for the inconvenience, I am a bit new to the
> process of emailing patches. Should I mark the next patch as v3?

Make sure the text you are quoting does above your reply.

This is called top-posting and is frowned upon.

Yes, please bump the version number - it will make the tooling happy.

> On Wed, 18 Nov 2020 at 18:13, Uwe Kleine-König
>  wrote:
> >
> > [added "v2" to the subject, would have been better if you had already
> > done that. I don't know if/how this confuses tools like b4 and patchwork]
> >
> > Hello,
> >
> > On Wed, Nov 18, 2020 at 04:17:30PM +0530, Soham Biswas wrote:
> > > Fixes the following warning generated by checkpatch:
> > >
> > > drivers/pwm/core.c:1341: WARNING: Symbolic permissions 'S_IRUGO' are
> > > not preferred. Consider using octal permissions '0444'.
> > >
> > > +debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> > >   &pwm_debugfs_fops);
> >
> > something like: "Permission bits are easier readable in octal than with
> > using the symbolic names." in the commit log would be good for those of
> > us who missed why this was added to checkpatch.
> >
> > Best regards
> > Uwe
> >
> >

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [mm/gup] 47e29d32af: phoronix-test-suite.npb.FT.A.total_mop_s -45.0% regression

2020-11-18 Thread Jan Kara

On Mon 16-11-20 19:35:31, John Hubbard wrote:
> 
> On 11/16/20 6:48 PM, kernel test robot wrote:
> > 
> > Greeting,
> > 
> > FYI, we noticed a -45.0% regression of 
> > phoronix-test-suite.npb.FT.A.total_mop_s due to commit:
> > 
> 
> That's a huge slowdown...
> 
> > 
> > commit: 47e29d32afba11b13efb51f03154a8cf22fb4360 ("mm/gup: 
> > page->hpage_pinned_refcount: exact pin counts for huge pages")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> ...but that commit happened in April, 2020. Surely if this were a serious
> issue we would have some other indication...is this worth following up
> on?? I'm inclined to ignore it, honestly.

Why this was detected so late is a fair question although it doesn't quite
invalidate the report... The NPB benchmark appears to be a supercomputing
benchmark so concievably it could be heavily using THPs. The question is
why it would be a heavy user of pinning as well but even that is imaginable
considering that MPI is in use etc.

So maybe it is worth trying to reproduce this because heavy THP + pinning
users might be indeed rare and only those would show regressions in THP
pinning performance...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] mmc: sdhci-of-arasan: Add pinctrl support to the driver

2020-11-18 Thread Michal Simek




On 18. 11. 20 7:21, Manish Narani wrote:
> Driver should be able to handle optional pinctrl setting.
> 
> Signed-off-by: Michal Simek 
> Signed-off-by: Manish Narani 
> ---
>  drivers/mmc/host/sdhci-of-arasan.c | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c 
> b/drivers/mmc/host/sdhci-of-arasan.c
> index 829ccef87426..f788cc9d5914 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "cqhci.h"
>  #include "sdhci-pltfm.h"
> @@ -135,6 +136,8 @@ struct sdhci_arasan_clk_data {
>   * @clk_ops: Struct for the Arasan Controller Clock Operations.
>   * @soc_ctl_base:Pointer to regmap for syscon for soc_ctl registers.
>   * @soc_ctl_map: Map to get offsets into soc_ctl registers.
> + * @pinctrl: Per-device pin control state holder.
> + * @pins_default:Pinctrl state for a device.
>   * @quirks:  Arasan deviations from spec.
>   */
>  struct sdhci_arasan_data {
> @@ -149,6 +152,8 @@ struct sdhci_arasan_data {
>  
>   struct regmap   *soc_ctl_base;
>   const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> + struct pinctrl  *pinctrl;
> + struct pinctrl_state *pins_default;
>   unsigned intquirks;
>  
>  /* Controller does not have CD wired and will not function normally without 
> */
> @@ -1619,6 +1624,25 @@ static int sdhci_arasan_probe(struct platform_device 
> *pdev)
>   goto unreg_clk;
>   }
>  
> + sdhci_arasan->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (!IS_ERR(sdhci_arasan->pinctrl)) {
> + sdhci_arasan->pins_default =
> + pinctrl_lookup_state(sdhci_arasan->pinctrl,
> +  PINCTRL_STATE_DEFAULT);
> + if (IS_ERR(sdhci_arasan->pins_default)) {
> + dev_err(&pdev->dev, "Missing default pinctrl config\n");
> + ret = PTR_ERR(sdhci_arasan->pins_default);
> + goto unreg_clk;
> + }
> +
> + ret = pinctrl_select_state(sdhci_arasan->pinctrl,
> +sdhci_arasan->pins_default);
> + if (ret) {
> + dev_err(&pdev->dev, "could not select default state\n");
> + goto unreg_clk;
> + }
> + }
> +
>   sdhci_arasan->phy = ERR_PTR(-ENODEV);
>   if (of_device_is_compatible(pdev->dev.of_node,
>   "arasan,sdhci-5.1")) {
> 

Ulf: Is there any need to describe in binding doc? I mean all txt based
binding have it described. But not quite sure if there is a need to
describe it in yaml if only default option is supported.
And when this is optional it should be fine also for others SOC.

For patch itself.

Acked-by: Michal Simek 

Thanks,
Michal

[PATCH] fail_function: remove a redundant mutex unlock

2020-11-18 Thread Masami Hiramatsu

From: Luo Meng 

Fix a mutex_unlock() issue where before copy_from_user() is
not called mutex_locked.

Fixes: 4b1a29a7f542 ("error-injection: Support fault injection framework")
Reported-by: Hulk Robot 
Acked-by: Masami Hiramatsu 
Signed-off-by: Luo Meng 
Signed-off-by: Masami Hiramatsu 
---
 0 files changed

diff --git a/kernel/fail_function.c b/kernel/fail_function.c
index 63b349168da7..b0b1ad93fa95 100644
--- a/kernel/fail_function.c
+++ b/kernel/fail_function.c
@@ -253,7 +253,7 @@ static ssize_t fei_write(struct file *file, const char 
__user *buffer,
 
if (copy_from_user(buf, buffer, count)) {
ret = -EFAULT;
-   goto out;
+   goto out_free;
}
buf[count] = '\0';
sym = strstrip(buf);
@@ -307,8 +307,9 @@ static ssize_t fei_write(struct file *file, const char 
__user *buffer,
ret = count;
}
 out:
-   kfree(buf);
mutex_unlock(&fei_lock);
+out_free:
+   kfree(buf);
return ret;
 }

[PATCH][next] drm/selftests/test-drm_dp_mst_helper: fix memory leak allocated to 'out'

From: Colin Ian King 

Currently when txmsg fails to allocate then there is a leak on 'out'. Fix
this by setting result to false and exiting via the clean up exit path.
Note since txmsg is NULL at this point, the kfree of txmsg is a no-op.

Addresses-Coverity: ("Resource leak")
Fixes: 09234b88ef55 ("drm/selftests/test-drm_dp_mst_helper: Move 
'sideband_msg_req_encode_decode' onto the heap")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c 
b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
index 6b4759ed6bfd..dbac073ed385 100644
--- a/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
+++ b/drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
@@ -131,8 +131,10 @@ sideband_msg_req_encode_decode(struct 
drm_dp_sideband_msg_req_body *in)
return false;
 
txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
-   if (!txmsg)
-   return false;
+   if (!txmsg) {
+   result = false;
+   goto out;
+   }
 
drm_dp_encode_sideband_req(in, txmsg);
ret = drm_dp_decode_sideband_req(txmsg, out);
-- 
2.28.0

Re: [PATCH v2] pwm: core: Use octal permission

2020-11-18 Thread Uwe Kleine-König

On Wed, Nov 18, 2020 at 07:11:35PM +0530, Soham Biswas wrote:
> Sure will do that. Sorry for the inconvenience, I am a bit new to the
> process of emailing patches. Should I mark the next patch as v3?

Yes, just pass -v3 to git-format-patch or git-send-email.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH 0/5] context_tracking: Flatter archs not using exception_enter/exit() v3

2020-11-18 Thread Frederic Weisbecker

On Wed, Nov 18, 2020 at 08:39:47AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 17, 2020 at 04:16:32PM +0100, Frederic Weisbecker wrote:
> > Frederic Weisbecker (5):
> >   context_tracking: Introduce HAVE_CONTEXT_TRACKING_OFFSTACK
> >   context_tracking:  Don't implement exception_enter/exit() on 
> > CONFIG_HAVE_CONTEXT_TRACKING_OFFSTACK
> >   sched: Detect call to schedule from critical entry code
> >   context_tracking: Only define schedule_user() on 
> > !HAVE_CONTEXT_TRACKING_OFFSTACK archs
> >   x86: Support HAVE_CONTEXT_TRACKING_OFFSTACK
> 
> Thanks!
> 
> Acked-by: Peter Zijlstra (Intel) 

Thanks! Probably this should go through your branches?

Re: [PATCH net-next v2 5/6] net/lapb: support netdev events

2020-11-18 Thread Xie He

On Wed, Nov 18, 2020 at 5:03 AM Xie He  wrote:
>
> On Wed, Nov 18, 2020 at 12:49 AM Martin Schiller  wrote:
> >
> > I also have a patch here that implements an "on demand" link feature,
> > which we used for ISDN dialing connections.
> > As ISDN is de facto dead, this is not relevant anymore. But if we want
> > such kind of feature, I think we need to stay with the method to control
> > L2 link state from L3.
>
> I see. Hmm...
>
> I guess for ISDN, the current code (before this patch series) is the
> best. We only establish the connection when L3 has packets to send.
>
> Can we do this? We let L2 handle all device-up / device-down /
> carrier-up / carrier-down events. And when L3 has some packets to send
> but it still finds the L2 link is not up, it will then instruct L2 to
> connect.
>
> This way we may be able to both keep the logic simple and still keep
> L3 compatible with ISDN.

Another solution might be letting ISDN automatically connect when it
receives the first packet from L3. This way we can still free L3 from
all handlings of L2 connections.

Re: [RFC PATCH V2] acpi/irq: Add stacked IRQ domain support to PCI interrupt link

2020-11-18 Thread Ard Biesheuvel

On Tue, 17 Nov 2020 at 19:57, Bjorn Helgaas  wrote:
>
> Nit: please don't just make up random styles for the subject.  Run
> "git log --oneline" on the file and/or the directory and try to follow
> the existing convention.  Using random styles adds noise to the
> system.
>
> On Tue, Nov 17, 2020 at 09:42:14PM +0800, Chen Baozi wrote:
> > Some PCIe designs require software to do extra acknowledgements for
> > legacy INTx interrupts. If the driver is written only for device tree,
> > things are simple. In that case, a new driver can be written under
> > driver/pci/controller/ with a DT node of PCIe host written like:
> >
> >   pcie {
> > ...
> > interrupt-map = <0 0 0  1  &pcie_intc 0>,
> > <0 0 0  2  &pcie_intc 1>,
> > <0 0 0  3  &pcie_intc 2>,
> > <0 0 0  4  &pcie_intc 3>;
> >
> > pcie_intc: legacy-interrupt-controller {
> >   interrupt-controller;
> >   #interrupt-cells = <1>;
> >   interrupt-parent = <&gic>;
> >   interrupts = <0 226 4>;
> > };
> >   };
> >
> > Similar designs can be found on Aardvark, MediaTek Gen2 and Socionext
> > UniPhier PCIe controller at the moment. Essentially, those designs are
> > supported by inserting an extra interrupt controller between PCIe host
> > and GIC and parse the topology in a DT-based PCI controller driver.
>
> If I understand correctly, we previously ignored the Resource Source
> field of an Extended Interrupt Descriptor in the _PRS method of
> PNP0C0F PCI Interrupt Link devices, and this patch adds support for
> it.
>
> If that's true, this has nothing to do with DT, other than DT being
> another way to describe the same topology, and the above details
> really aren't relevant to this patch.
>
> > As we turn to ACPI, All the PCIe hosts are described the same ID of
> > "PNP0A03" and share driver/acpi/pci_root.c. It comes to be a problem
> > to make this kind of PCI INTx work under ACPI.
>
> s/All the PCIe/all the PCIe/
>
> But this paragraph should probably just go away in favor of something
> about implementing Resource Source support.
>
> > Therefore, we introduce an stacked IRQ domain support to PCI interrupt
> > link for ACPI. With this support, we can populate the ResourceSource
> > to refer to a device object that describes an interrupt controller.
> > That would allow us to refer to a dedicated driver which implements
> > the logic needed to manage the interrupt state. With this patch,
> > those PCI interrupt links can be supported by describing the INTx
> > in ACPI table as the following example:
>
> "Stacked IRQ domain" sounds like a detail of how you're implementing
> support for the Resource Source field for PCI Interrupt Links.
>
> I don't know what the dedicated driver refers to.  This *should* be
> all generic code the follows the ACPI spec (which is pretty sketchy in
> this area).  But I assume that there's no special driver needed for
> devices like \SB.IXIU, and the logic associated with the interrupt
> controller is in the AML associated with IXIU.  It would probably be
> useful to mention the relevant methods in the IXIU methods in the
> example below.
>

As I understand it, the intent is to provide a driver for \SB.IXIU
that acknowledges the legacy INTx interrupts in a SoC specific way,
and I don't see how AML could be involved here.

That also explains why the routines are exported to modules - the IXIU
driver could be modularized.


> From ACPI v6.3, Table 6-200, it looks like this patch should include
> changes to acpi_bus_osc_support() to advertise "Interrupt
> ResourceSource support".
>

I assume this covers all uses of ResourceSource, right? Not only in
the context if PCIe legacy interrupts?

> >   Device (IXIU) {
> > ...
> >   }
> >
> >   Device(LINKA) {
> > Name(_HID, EISAID("PNP0C0F"))
> > Name(_PRS, ResourceTemplate(){
> >   Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive, 0, 
> > "\\SB.IXIU")
> > { 60 }
> > })
> > ...
> >   }
> >
> >   Device(PCI0) {
> > ...
> > Name(_PRT, Package{
> >   Package{ 0x, 0, LINKA, 0 }
> >   ...
> > })
> >   }
> >
> > Signed-off-by: Chen Baozi 
> > ---
> >  drivers/acpi/irq.c  | 22 +-
> >  drivers/acpi/pci_irq.c  |  6 --
> >  drivers/acpi/pci_link.c | 17 +++--
> >  include/acpi/acpi_drivers.h |  2 +-
> >  include/linux/acpi.h|  4 
> >  5 files changed, 45 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/acpi/irq.c b/drivers/acpi/irq.c
> > index e209081d644b..e78a44815c44 100644
> > --- a/drivers/acpi/irq.c
> > +++ b/drivers/acpi/irq.c
> > @@ -81,6 +81,25 @@ void acpi_unregister_gsi(u32 gsi)
> >  }
> >  EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
> >
> > +int acpi_register_irq(struct device *dev, u32 irq, int trigger,
> > +   int polarity, struct fwnode_handle *domain_id)
> > +{
> > + struct irq_fwspec fwspec;
> > +
> > + if (WARN_ON(!domain_id)) {
> > +

Re: [PATCH 4.19 031/101] ALSA: hda: Reinstate runtime_allow() for all hda controllers

2020-11-18 Thread Sasha Levin


On Wed, Nov 18, 2020 at 11:43:16AM +0100, Pavel Machek wrote:

Hi!


From: Kai-Heng Feng 

[ Upstream commit 9fc149c3bce7bdbb94948a8e6bd025e3b3538603 ]

The broken jack detection should be fixed by commit a6e7d0a4bdb0 ("ALSA:
hda: fix jack detection with Realtek codecs when in D3"), let's try
enabling runtime PM by default again.


I believe experiments should be done in mainline, not in stable.

Worse problem is that a6e7d0a4bdb0 is not in 4.19-stable, so this will
likely break jack detection.


I've dropped it from 4.19, thanks!

--
Thanks,
Sasha

Re: [PATCH net-next V5] net: Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO

2020-11-18 Thread Dmytro Shytyi

Hello,

 On Tue, 17 Nov 2020 21:43:48 +0100 Jakub Kicinski  wrote 


 > On Fri, 13 Nov 2020 20:36:58 +0100 Dmytro Shytyi wrote: 
 > > Variable SLAAC: SLAAC with prefixes of arbitrary length in PIO (randomly 
 > > generated hostID or stable privacy + privacy extensions). 
 > > The main problem is that SLAAC RA or PD allocates a /64 by the Wireless 
 > > carrier 4G, 5G to a mobile hotspot, however segmentation of the /64 via 
 > > SLAAC is required so that downstream interfaces can be further subnetted. 
 > > Example: uCPE device (4G + WI-FI enabled) receives /64 via Wireless, and 
 > > assigns /72 to VNF-Firewall, /72 to WIFI, /72 to VNF-Router, /72 to 
 > > Load-Balancer and /72 to wired connected devices. 
 > > IETF document that defines problem statement: 
 > > draft-mishra-v6ops-variable-slaac-problem-stmt 
 > > IETF document that specifies variable slaac: 
 > > draft-mishra-6man-variable-slaac 
 > > 
 > > Signed-off-by: Dmytro Shytyi  
 > > --- 
 > > diff -rupN net-next-5.10.0-rc2/include/net/if_inet6.h 
 > > net-next-patch-5.10.0-rc2/include/net/if_inet6.h 
 > > --- net-next-5.10.0-rc2/include/net/if_inet6.h2020-11-10 
 > > 08:46:00.195180579 +0100 
 > > +++ net-next-patch-5.10.0-rc2/include/net/if_inet6.h2020-11-11 
 > > 18:11:05.627550135 +0100 
 > > @@ -22,6 +22,12 @@ 
 > >  #define IF_RS_SENT0x10 
 > >  #define IF_READY0x8000 
 > > 
 > > +/* Variable SLAAC (Contact: Dmytro Shytyi) 
 > > + * draft-mishra-6man-variable-slaac 
 > > + * draft-mishra-v6ops-variable-slaac-problem-stmt 
 > > + */ 
 > > +#define IF_RA_VAR_PLEN0x08 
 > > + 
 > >  /* prefix flags */ 
 > >  #define IF_PREFIX_ONLINK0x01 
 > >  #define IF_PREFIX_AUTOCONF0x02 
 > > diff -rupN net-next-5.10.0-rc2/include/uapi/linux/icmpv6.h 
 > > net-next-patch-5.10.0-rc2/include/uapi/linux/icmpv6.h 
 > > --- net-next-5.10.0-rc2/include/uapi/linux/icmpv6.h2020-11-10 
 > > 08:46:00.351849525 +0100 
 > > +++ net-next-patch-5.10.0-rc2/include/uapi/linux/icmpv6.h2020-11-11 
 > > 18:11:05.627550135 +0100 
 > > @@ -42,7 +42,9 @@ struct icmp6hdr { 
 > >  struct icmpv6_nd_ra { 
 > >  __u8hop_limit; 
 > >  #if defined(__LITTLE_ENDIAN_BITFIELD) 
 > > -__u8reserved:3, 
 > > +__u8reserved:1, 
 > > +slaac_var_plen:1, 
 > > +proxy:1, 
 >  
 > What's the status of your draft? I'm not too familiar with the IETF 
 > process, but I'm not sure we should change uAPI headers before the 
 > draft reaches reasonable consensus. 
 >  
 > I'd appreciate extra opinions here. 

Okay, we may avoid modification of the uAPI headers as plen (prefix length 
!=64) itself serves as a flag to activate the "Variable SLAAC"
I will modify the patch accordingly.

 > >  router_pref:2, 
 > >  home_agent:1, 
 > >  other:1, 
 > > @@ -53,7 +55,9 @@ struct icmp6hdr { 
 > >  other:1, 
 > >  home_agent:1, 
 > >  router_pref:2, 
 > > -reserved:3; 
 > > +proxy:1, 
 > > +slaac_var_plen:1, 
 > > +reserved:1; 
 > >  #else 
 > >  #error"Please fix " 
 > >  #endif 
 > > @@ -78,9 +82,9 @@ struct icmp6hdr { 
 > >  #define icmp6_addrconf_othericmp6_dataun.u_nd_ra.other 
 > >  #define icmp6_rt_lifetimeicmp6_dataun.u_nd_ra.rt_lifetime 
 > >  #define icmp6_router_preficmp6_dataun.u_nd_ra.router_pref 
 > > +#define icmp6_slaac_var_plenicmp6_dataun.u_nd_ra.slaac_var_plen 
 > >  }; 
 > > 
 > > - 
 > >  #define ICMPV6_ROUTER_PREF_LOW0x3 
 > >  #define ICMPV6_ROUTER_PREF_MEDIUM0x0 
 > >  #define ICMPV6_ROUTER_PREF_HIGH0x1 
 > > diff -rupN net-next-5.10.0-rc2/net/ipv6/addrconf.c 
 > > net-next-patch-5.10.0-rc2/net/ipv6/addrconf.c 
 > > --- net-next-5.10.0-rc2/net/ipv6/addrconf.c2020-11-10 
 > > 08:46:01.075193379 +0100 
 > > +++ net-next-patch-5.10.0-rc2/net/ipv6/addrconf.c2020-11-13 
 > > 19:50:04.401227310 +0100 
 > > @@ -11,6 +11,8 @@ 
 > >  /* 
 > >   *Changes: 
 > >   * 
 > > + *Dmytro Shytyi:Variable SLAAC: SLAAC with 
 > > + *prefixes of arbitrary length. 
 >  
 > Please don't add your name to those headers. We have git now, 
 > authorship if clearly preserved. 

Understood.

 > >   *Janos Farkas:delete timer on ifdown 
 > >   * 
 > >   *Andi Kleen:kill double kfree on module 
 > > @@ -142,7 +144,11 @@ static int ipv6_count_addresses(const st 
 > >  static int ipv6_generate_stable_address(struct in6_addr *addr, 
 > >  u8 dad_count, 
 > >  const struct inet6_dev *idev); 
 > > - 
 > > +static int ipv6_generate_address_variable_plen(struct in6_addr *address, 
 > > +   u8 dad_count, 
 > > +   const struct inet6_dev *idev, 
 > > +

Re: [PATCH v2] pwm: core: Use octal permission

2020-11-18 Thread Soham Biswas

Sure will do that. Sorry for the inconvenience, I am a bit new to the
process of emailing patches. Should I mark the next patch as v3?

On Wed, 18 Nov 2020 at 18:13, Uwe Kleine-König
 wrote:
>
> [added "v2" to the subject, would have been better if you had already
> done that. I don't know if/how this confuses tools like b4 and patchwork]
>
> Hello,
>
> On Wed, Nov 18, 2020 at 04:17:30PM +0530, Soham Biswas wrote:
> > Fixes the following warning generated by checkpatch:
> >
> > drivers/pwm/core.c:1341: WARNING: Symbolic permissions 'S_IRUGO' are
> > not preferred. Consider using octal permissions '0444'.
> >
> > +debugfs_create_file("pwm", S_IFREG | S_IRUGO, NULL, NULL,
> >   &pwm_debugfs_fops);
>
> something like: "Permission bits are easier readable in octal than with
> using the symbolic names." in the commit log would be good for those of
> us who missed why this was added to checkpatch.
>
> Best regards
> Uwe
>
>
> --
> Pengutronix e.K.   | Uwe Kleine-König|
> Industrial Linux Solutions | https://www.pengutronix.de/ |

Re: [PATCH v5 7/8] [DNI] arm64: dts: renesas: salvator-x-max9286: Specify channel amplitude

2020-11-18 Thread Kieran Bingham

Hi Jacopo,

On 16/11/2020 13:53, Jacopo Mondi wrote:
> Use the newly introduced 'maxim,initial-reverse-channel-mV'
> property to specify the initial reverse channel amplitude when
> the remote serializers are pre-programmed with noise immunity threshold
> enabled.
> 
> Signed-off-by: Jacopo Mondi 

Tested-by: Kieran Bingham 
Reviewed-by: Kieran Bingham 



> ---
>  arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi 
> b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
> index 6f4798859542..f14a133b7302 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-x-max9286.dtsi
> @@ -128,6 +128,7 @@ gmsl-deserializer@4c {
>   compatible = "maxim,max9286";
>   reg = <0x4c>;
>   poc-supply = <&poc_12v>;
> + maxim,initial-reverse-channel-mV = <170>;
>  
>   ports {
>   #address-cells = <1>;
> @@ -263,6 +264,7 @@ gmsl-deserializer@6c {
>   compatible = "maxim,max9286";
>   reg = <0x6c>;
>   poc-supply = <&poc_12v>;
> + maxim,initial-reverse-channel-mV = <170>;
>  
>   ports {
>   #address-cells = <1>;
>

Re: possible deadlock in _destroy_id

2020-11-18 Thread Jason Gunthorpe

On Wed, Nov 18, 2020 at 03:10:21AM -0800, syzbot wrote:

> HEAD commit:20529233 Add linux-next specific files for 20201118
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13093cf250
> kernel config:  https://syzkaller.appspot.com/x/.config?x=2c4fb58b6526b3c1
> dashboard link: https://syzkaller.appspot.com/bug?extid=1bc48bf7f78253f664a9
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> 
> Unfortunately, I don't have any reproducer for this issue yet.

Oh? Is this because the error injection is too random?
 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+1bc48bf7f78253f66...@syzkaller.appspotmail.com
> 
> iwpm_register_pid: Unable to send a nlmsg (client = 2)
> infiniband syz1: RDMA CMA: cma_listen_on_dev, error -98
> 
> WARNING: possible recursive locking detected
> 5.10.0-rc4-next-20201118-syzkaller #0 Not tainted
> syz-executor.5/12844 is trying to acquire lock:
> 8c684748 (lock#6){+.+.}-{3:3}, at: cma_release_dev 
> drivers/infiniband/core/cma.c:476 [inline]
> 8c684748 (lock#6){+.+.}-{3:3}, at: _destroy_id+0x299/0xa00 
> drivers/infiniband/core/cma.c:1852
> 
> but task is already holding lock:
> 8c684748 (lock#6){+.+.}-{3:3}, at: cma_add_one+0x55c/0xce0 
> drivers/infiniband/core/cma.c:4902

Leon, this is caused by

commit c80a0c52d85c49a910d0dc0e342e8d8898677dc0
Author: Leon Romanovsky 
Date:   Wed Nov 4 16:40:07 2020 +0200

RDMA/cma: Add missing error handling of listen_id

Don't silently continue if rdma_listen() fails but destroy previously
created CM_ID and return an error to the caller.

rdma_destroy_id() can't be called while holding the global lock

This is quite hard to fix. I came up with this ugly thing:

>From 8e6568f99fbe4bf734cc4e5dcda987e4ae118bdd Mon Sep 17 00:00:00 2001
From: Jason Gunthorpe 
Date: Wed, 18 Nov 2020 09:33:23 -0400
Subject: [PATCH] RDMA/cma: Fix deadlock on &lock in rdma_cma_listen_on_all()
 error unwind

rdma_detroy_id() cannot be called under &lock - we must instead keep the
error'd ID around until &lock can be released, then destory it.

This is complicated by the usual way listen IDs are destroyed through
cma_process_remove() which can run at any time and will asynchronously
destroy the same ID.

Remove the ID from visiblity of cma_process_remove() before going down the
destroy path outside the locking.

Fixes: c80a0c52d85c ("RDMA/cma: Add missing error handling of listen_id")
Reported-by: syzbot+1bc48bf7f78253f66...@syzkaller.appspotmail.com
Signed-off-by: Jason Gunthorpe 
---
 drivers/infiniband/core/cma.c | 25 ++---
 1 file changed, 18 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 4585f654f88369..c06c87a4dc5e7d 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2496,7 +2496,8 @@ static int cma_listen_handler(struct rdma_cm_id *id,
 }
 
 static int cma_listen_on_dev(struct rdma_id_private *id_priv,
-struct cma_device *cma_dev)
+struct cma_device *cma_dev,
+struct rdma_id_private **to_destroy)
 {
struct rdma_id_private *dev_id_priv;
struct net *net = id_priv->id.route.addr.dev_addr.net;
@@ -2504,6 +2505,7 @@ static int cma_listen_on_dev(struct rdma_id_private 
*id_priv,
 
lockdep_assert_held(&lock);
 
+   *to_destroy = NULL;
if (cma_family(id_priv) == AF_IB && !rdma_cap_ib_cm(cma_dev->device, 1))
return 0;
 
@@ -2518,7 +2520,6 @@ static int cma_listen_on_dev(struct rdma_id_private 
*id_priv,
   rdma_addr_size(cma_src_addr(id_priv)));
 
_cma_attach_to_dev(dev_id_priv, cma_dev);
-   list_add_tail(&dev_id_priv->listen_list, &id_priv->listen_list);
cma_id_get(id_priv);
dev_id_priv->internal_id = 1;
dev_id_priv->afonly = id_priv->afonly;
@@ -2528,25 +2529,31 @@ static int cma_listen_on_dev(struct rdma_id_private 
*id_priv,
ret = rdma_listen(&dev_id_priv->id, id_priv->backlog);
if (ret)
goto err_listen;
+   list_add_tail(&dev_id_priv->listen_list, &id_priv->listen_list);
return 0;
 err_listen:
-   list_del(&id_priv->listen_list);
+   /* Caller must destroy this after releasing lock */
+   *to_destroy = dev_id_priv;
dev_warn(&cma_dev->device->dev, "RDMA CMA: %s, error %d\n", __func__, 
ret);
-   rdma_destroy_id(&dev_id_priv->id);
return ret;
 }
 
 static int cma_listen_on_all(struct rdma_id_private *id_priv)
 {
+   struct rdma_id_private *to_destroy;
struct cma_device *cma_d

Re: [PATCH] fail_function: remove a redundant mutex unlock

2020-11-18 Thread Masami Hiramatsu

Hi,

On Tue, 17 Nov 2020 20:08:08 -0800
Alexei Starovoitov  wrote:

> On Wed, Nov 11, 2020 at 1:31 AM Masami Hiramatsu  wrote:
> >
> > Hi Luo,
> >
> > On Tue, 10 Nov 2020 16:42:45 +0800
> > Luo Meng  wrote:
> >
> > > Fix a mutex_unlock() issue where before copy_from_user() is
> > > not called mutex_locked.
> >
> > Oops, thank you for the fix.
> >
> > Acked-by: Masami Hiramatsu 
> 
> Did anyone pick this up?
> If not, please resend cc-ing bpf@vger so it can get into patchwork and
> be processed by bpf maintainers.

OK, I'll resend this to the bpf@vger. 

Thank you,

> 
> Thanks!
> 
> > >
> > > Fixes: 4b1a29a7f542 ("error-injection: Support fault injection framework")
> > > Reported-by: Hulk Robot 
> > > Signed-off-by: Luo Meng 
> > > ---
> > >  kernel/fail_function.c | 5 +++--
> > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/fail_function.c b/kernel/fail_function.c
> > > index 63b349168da7..b0b1ad93fa95 100644
> > > --- a/kernel/fail_function.c
> > > +++ b/kernel/fail_function.c
> > > @@ -253,7 +253,7 @@ static ssize_t fei_write(struct file *file, const 
> > > char __user *buffer,
> > >
> > >   if (copy_from_user(buf, buffer, count)) {
> > >   ret = -EFAULT;
> > > - goto out;
> > > + goto out_free;
> > >   }
> > >   buf[count] = '\0';
> > >   sym = strstrip(buf);
> > > @@ -307,8 +307,9 @@ static ssize_t fei_write(struct file *file, const 
> > > char __user *buffer,
> > >   ret = count;
> > >   }
> > >  out:
> > > - kfree(buf);
> > >   mutex_unlock(&fei_lock);
> > > +out_free:
> > > + kfree(buf);
> > >   return ret;
> > >  }
> > >
> > > --
> > > 2.25.4
> > >
> >
> >
> > --
> > Masami Hiramatsu 


-- 
Masami Hiramatsu

[PATCH][next] scsi: lpfc: remove dead code on second !ndlp check