Re: [PATCH 8/9] rpmsg: virtio: use rpmsg_ns driver to manage ns announcement
Hi Arnaud,
On Fri, Jul 31, 2020 at 01:47:31PM +0200, Arnaud Pouliquen wrote:
> Use the new rpmsg_ns API to send the name service announcements if
> the VIRTIO_RPMSG_F_NS is set, else just not implement the ops.
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 94 +---
> 1 file changed, 13 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c
> b/drivers/rpmsg/virtio_rpmsg_bus.c
> index f771fdae150e..3c771a6392be 100644
> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> @@ -91,35 +91,6 @@ struct rpmsg_hdr {
> u8 data[];
> } __packed;
>
> -/**
> - * struct rpmsg_ns_msg - dynamic name service announcement message
> - * @name: name of remote service that is published
> - * @addr: address of remote service that is published
> - * @flags: indicates whether service is created or destroyed
> - *
> - * This message is sent across to publish a new service, or announce
> - * about its removal. When we receive these messages, an appropriate
> - * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
> - * or ->remove() handler of the appropriate rpmsg driver will be invoked
> - * (if/as-soon-as one is registered).
> - */
> -struct rpmsg_ns_msg {
> - char name[RPMSG_NAME_SIZE];
> - __virtio32 addr;
> - __virtio32 flags;
> -} __packed;
> -
> -/**
> - * enum rpmsg_ns_flags - dynamic name service announcement flags
> - *
> - * @RPMSG_NS_CREATE: a new remote service was just created
> - * @RPMSG_NS_DESTROY: a known remote service was just destroyed
> - */
> -enum rpmsg_ns_flags {
> - RPMSG_NS_CREATE = 0,
> - RPMSG_NS_DESTROY= 1,
> -};
> -
> /**
> * @vrp: the remote processor this channel belongs to
> */
> @@ -324,60 +295,18 @@ static void virtio_rpmsg_destroy_ept(struct
> rpmsg_endpoint *ept)
> __rpmsg_destroy_ept(vch->vrp, ept);
> }
>
> -static int virtio_rpmsg_announce_create(struct rpmsg_device *rpdev)
> -{
> - struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> - struct virtproc_info *vrp = vch->vrp;
> - struct device *dev = >dev;
> - int err = 0;
> -
> - /* need to tell remote processor's name service about this channel ? */
> - if (rpdev->announce && rpdev->ept &&
> - virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
> - struct rpmsg_ns_msg nsm;
> -
> - strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
> - nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
> - nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_CREATE);
> -
> - err = rpmsg_sendto(rpdev->ept, , sizeof(nsm),
> RPMSG_NS_ADDR);
> - if (err)
> - dev_err(dev, "failed to announce service %d\n", err);
> - }
> -
> - return err;
> -}
> -
> -static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
> -{
> - struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
> - struct virtproc_info *vrp = vch->vrp;
> - struct device *dev = >dev;
> - int err = 0;
> -
> - /* tell remote processor's name service we're removing this channel */
> - if (rpdev->announce && rpdev->ept &&
> - virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
> - struct rpmsg_ns_msg nsm;
> -
> - strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
> - nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
> - nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_DESTROY);
> -
> - err = rpmsg_sendto(rpdev->ept, , sizeof(nsm),
> RPMSG_NS_ADDR);
> - if (err)
> - dev_err(dev, "failed to announce service %d\n", err);
> - }
> -
> - return err;
> -}
> -
> static const struct rpmsg_device_ops virtio_rpmsg_ops = {
> .create_channel = virtio_rpmsg_create_channel,
> .release_channel = virtio_rpmsg_release_channel,
> .create_ept = virtio_rpmsg_create_ept,
> - .announce_create = virtio_rpmsg_announce_create,
> - .announce_destroy = virtio_rpmsg_announce_destroy,
> +};
> +
> +static const struct rpmsg_device_ops virtio_rpmsg_w_nsa_ops = {
> + .create_channel = virtio_rpmsg_create_channel,
> + .release_channel = virtio_rpmsg_release_channel,
> + .create_ept = virtio_rpmsg_create_ept,
> + .announce_create = rpmsg_ns_announce_create,
> + .announce_destroy = rpmsg_ns_announce_destroy,
> };
>
> static void virtio_rpmsg_release_device(struct device *dev)
> @@ -423,7 +352,10 @@ __rpmsg_create_channel(struct virtproc_info *vrp,
> rpdev = >rpdev;
> rpdev->src = chinfo->src;
> rpdev->dst = chinfo->dst;
> - rpdev->ops = _rpmsg_ops;
> + if (virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS))
> + rpdev->ops = _rpmsg_w_nsa_ops;
> + else
> + rpdev->ops = _rpmsg_ops;
Yesterday I struggled with this part and I still do this
[PATCH v2 2/8] rpmsg: core: add channel creation internal API
Add the channel creation API as a first step to be able to define the
name service announcement as a rpmsg driver independent from the RPMsg
virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_core.c | 45 ++
drivers/rpmsg/rpmsg_internal.h | 12 +
2 files changed, 57 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index a6361cad608b..97c15c1a0cc8 100644
--- a/drivers/rpmsg/rpmsg_core.c
+++ b/drivers/rpmsg/rpmsg_core.c
@@ -20,6 +20,51 @@
#include "rpmsg_internal.h"
+/**
+ * rpmsg_create_channel() - create a new rpmsg channel
+ * using its name and address info.
+ * @rpdev: rpmsg driver
+ * @chinfo: channel_info to bind
+ *
+ * Returns a pointer to the new rpmsg device on success, or NULL on error.
+ */
+struct rpmsg_device *
+ rpmsg_create_channel(struct rpmsg_device *rpdev,
+struct rpmsg_channel_info *chinfo)
+{
+ if (WARN_ON(!rpdev))
+ return NULL;
+ if (!rpdev->ops || !rpdev->ops->create_channel) {
+ dev_err(>dev, "no create_channel ops found\n");
+ return NULL;
+ }
+
+ return rpdev->ops->create_channel(rpdev, chinfo);
+}
+EXPORT_SYMBOL(rpmsg_create_channel);
+
+/**
+ * rpmsg_release_channel() - release a rpmsg channel
+ * using its name and address info.
+ * @rpdev: rpmsg driver
+ * @chinfo: channel_info to bind
+ *
+ * Returns 0 on success or an appropriate error value.
+ */
+int rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ if (WARN_ON(!rpdev))
+ return -EINVAL;
+ if (!rpdev->ops || !rpdev->ops->release_channel) {
+ dev_err(>dev, "no release_channel ops found\n");
+ return -EPERM;
+ }
+
+ return rpdev->ops->release_channel(rpdev, chinfo);
+}
+EXPORT_SYMBOL(rpmsg_release_channel);
+
/**
* rpmsg_create_ept() - create a new rpmsg_endpoint
* @rpdev: rpmsg channel device
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 3fc83cd50e98..d5ab286d0e5e 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -20,6 +20,8 @@
/**
* struct rpmsg_device_ops - indirection table for the rpmsg_device operations
+ * @create_channel:create backend-specific channel, optional
+ * @release_channel: release backend-specific channel, optional
* @create_ept:create backend-specific endpoint, required
* @announce_create: announce presence of new channel, optional
* @announce_destroy: announce destruction of channel, optional
@@ -29,6 +31,11 @@
* advertise new channels implicitly by creating the endpoints.
*/
struct rpmsg_device_ops {
+ struct rpmsg_device *(*create_channel)(struct rpmsg_device *rpdev,
+struct rpmsg_channel_info *chinfo);
+ int (*release_channel)(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
+
struct rpmsg_endpoint *(*create_ept)(struct rpmsg_device *rpdev,
rpmsg_rx_cb_t cb, void *priv,
struct rpmsg_channel_info chinfo);
@@ -75,6 +82,11 @@ int rpmsg_unregister_device(struct device *parent,
struct device *rpmsg_find_device(struct device *parent,
struct rpmsg_channel_info *chinfo);
+struct rpmsg_device *
+ rpmsg_create_channel(struct rpmsg_device *rpdev,
+struct rpmsg_channel_info *chinfo);
+int rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
/**
* rpmsg_chrdev_register_device() - register chrdev device based on rpdev
* @rpdev: prepared rpdev to be used for creating endpoints
--
2.17.1
[PATCH v2 0/8] introduce name service announcement rpmsg driver
The NS announcement is implemented by several backends, but could be considered as part the RPMsg protocol. In this case it should be managed as a reserved rpmsg service and so implemented on top of the rpmsg protocol. This series introduces the rpmsg_ns driver that handles the name service announcement. The virtio backend is updated in consequence to use this service. Applies cleanly on Bjorn for-next branch (ca69dba7f13a) Main updates from V1 to V2: - Integrate Mathieu's comments: - rework the rpmsg_create_channel and rpmsg_release_channel error management. - merge patch "[9/9] rpmsg: ns: name service announcement endianness" in other pathes. V1: https://patchwork.kernel.org/project/linux-remoteproc/list/?series=327257 Arnaud Pouliquen (8): rpmsg: virtio: rename rpmsg_create_channel rpmsg: core: add channel creation internal API rpmsg: virtio: add rpmsg channel device ops rpmsg: define the name service announcement as reserved address rpmsg: introduce reserved rpmsg driver for ns announcement rpmsg: virtio: use rpmsg ns device for the ns announcement rpmsg: ns: add name service announcement service rpmsg: virtio: use rpmsg_ns driver to manage ns announcement drivers/rpmsg/Kconfig| 9 ++ drivers/rpmsg/Makefile | 1 + drivers/rpmsg/rpmsg_core.c | 45 +++ drivers/rpmsg/rpmsg_internal.h | 32 + drivers/rpmsg/rpmsg_ns.c | 174 + drivers/rpmsg/virtio_rpmsg_bus.c | 213 +-- include/linux/rpmsg.h| 9 ++ 7 files changed, 332 insertions(+), 151 deletions(-) create mode 100644 drivers/rpmsg/rpmsg_ns.c -- 2.17.1
[PATCH v2 8/8] rpmsg: virtio: use rpmsg_ns driver to manage ns announcement
Use the new rpmsg_ns API to send the name service announcements if
the VIRTIO_RPMSG_F_NS is set, else just not implement the ops.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 94 +---
1 file changed, 13 insertions(+), 81 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index f771fdae150e..3c771a6392be 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -91,35 +91,6 @@ struct rpmsg_hdr {
u8 data[];
} __packed;
-/**
- * struct rpmsg_ns_msg - dynamic name service announcement message
- * @name: name of remote service that is published
- * @addr: address of remote service that is published
- * @flags: indicates whether service is created or destroyed
- *
- * This message is sent across to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
- char name[RPMSG_NAME_SIZE];
- __virtio32 addr;
- __virtio32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
- RPMSG_NS_CREATE = 0,
- RPMSG_NS_DESTROY= 1,
-};
-
/**
* @vrp: the remote processor this channel belongs to
*/
@@ -324,60 +295,18 @@ static void virtio_rpmsg_destroy_ept(struct
rpmsg_endpoint *ept)
__rpmsg_destroy_ept(vch->vrp, ept);
}
-static int virtio_rpmsg_announce_create(struct rpmsg_device *rpdev)
-{
- struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
- struct virtproc_info *vrp = vch->vrp;
- struct device *dev = >dev;
- int err = 0;
-
- /* need to tell remote processor's name service about this channel ? */
- if (rpdev->announce && rpdev->ept &&
- virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
- struct rpmsg_ns_msg nsm;
-
- strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
- nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
- nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_CREATE);
-
- err = rpmsg_sendto(rpdev->ept, , sizeof(nsm),
RPMSG_NS_ADDR);
- if (err)
- dev_err(dev, "failed to announce service %d\n", err);
- }
-
- return err;
-}
-
-static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
-{
- struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
- struct virtproc_info *vrp = vch->vrp;
- struct device *dev = >dev;
- int err = 0;
-
- /* tell remote processor's name service we're removing this channel */
- if (rpdev->announce && rpdev->ept &&
- virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
- struct rpmsg_ns_msg nsm;
-
- strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
- nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
- nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_DESTROY);
-
- err = rpmsg_sendto(rpdev->ept, , sizeof(nsm),
RPMSG_NS_ADDR);
- if (err)
- dev_err(dev, "failed to announce service %d\n", err);
- }
-
- return err;
-}
-
static const struct rpmsg_device_ops virtio_rpmsg_ops = {
.create_channel = virtio_rpmsg_create_channel,
.release_channel = virtio_rpmsg_release_channel,
.create_ept = virtio_rpmsg_create_ept,
- .announce_create = virtio_rpmsg_announce_create,
- .announce_destroy = virtio_rpmsg_announce_destroy,
+};
+
+static const struct rpmsg_device_ops virtio_rpmsg_w_nsa_ops = {
+ .create_channel = virtio_rpmsg_create_channel,
+ .release_channel = virtio_rpmsg_release_channel,
+ .create_ept = virtio_rpmsg_create_ept,
+ .announce_create = rpmsg_ns_announce_create,
+ .announce_destroy = rpmsg_ns_announce_destroy,
};
static void virtio_rpmsg_release_device(struct device *dev)
@@ -423,7 +352,10 @@ __rpmsg_create_channel(struct virtproc_info *vrp,
rpdev = >rpdev;
rpdev->src = chinfo->src;
rpdev->dst = chinfo->dst;
- rpdev->ops = _rpmsg_ops;
+ if (virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS))
+ rpdev->ops = _rpmsg_w_nsa_ops;
+ else
+ rpdev->ops = _rpmsg_ops;
/*
* rpmsg server channels has predefined local address (for now),
@@ -933,7 +865,7 @@ static int rpmsg_probe(struct virtio_device *vdev)
/* Assign public information to the rpmsg_device */
rpdev_ns = >rpdev;
-
[PATCH v2 4/8] rpmsg: define the name service announcement as reserved address
The address 53 is reserved for the dynamic RPMsg device management
on name service announcement.
Define this address in a reserved enum list.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 3 ---
include/linux/rpmsg.h| 9 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 910d30818901..b2927661868c 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -162,9 +162,6 @@ struct virtio_rpmsg_channel {
*/
#define RPMSG_RESERVED_ADDRESSES (1024)
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR (53)
-
static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/rpmsg.h b/include/linux/rpmsg.h
index 9fe156d1c018..5496d27c6f8c 100644
--- a/include/linux/rpmsg.h
+++ b/include/linux/rpmsg.h
@@ -20,6 +20,15 @@
#define RPMSG_ADDR_ANY 0x
+/**
+ * enum rpmsg_ns_flags - List of reserved RPMsg addresses
+ *
+ * @RPMSG_NS_ADDR: remote services advertising for dynamic allocation
+ */
+enum rpmsg_reserved_addr {
+ RPMSG_NS_ADDR = 53,
+};
+
struct rpmsg_device;
struct rpmsg_endpoint;
struct rpmsg_device_ops;
--
2.17.1
[PATCH v2 7/8] rpmsg: ns: add name service announcement service
As the RPMsg driver is in charge of the name service announcement,
create an API to send channel creation and destruction to the remote
processor.
Notice that the source address of the message sent is now RPMSG_NS_ADDR.
Legacy implementation was to send the message with source address
corresponding to the ept created.
RPMSG_NS_ADDR as source address make sense as we want to send a message
belonging to the NS announcement service and the created ept address is
already in the message payload.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/rpmsg_internal.h | 3 +++
drivers/rpmsg/rpmsg_ns.c | 39 ++
2 files changed, 42 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index 641b48f6bf2a..d1549e5cb607 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -119,4 +119,7 @@ static inline int rpmsg_ns_register_device(struct
rpmsg_device *rpdev)
return rpmsg_register_device(rpdev);
}
+int rpmsg_ns_announce_create(struct rpmsg_device *rpdev);
+int rpmsg_ns_announce_destroy(struct rpmsg_device *rpdev);
+
#endif
diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c
index 3c929b6976a6..2a34e36a592d 100644
--- a/drivers/rpmsg/rpmsg_ns.c
+++ b/drivers/rpmsg/rpmsg_ns.c
@@ -37,6 +37,45 @@ struct rpmsg_ns_msg {
__le32 flags;
} __packed;
+/**
+ * rpmsg_ns_announce_create() - announce to the remote processor
+ * the service creation or destruction
+ * @rpdev: the rpmsg channel
+ * @ns_flag: related to the @rpmsg_ns_flags enum
+ *
+ * This function can be called on a channel creation or destruction to inform
+ * the remote processor, using the reserved name service anouncement channel.
+ */
+static int rpmsg_ns_channel_announce(struct rpmsg_device *rpdev, int ns_flag)
+{
+ struct rpmsg_ns_msg nsm;
+
+ if (!rpdev->announce || !rpdev->ept)
+ return 0;
+
+ if (ns_flag != RPMSG_NS_CREATE && ns_flag != RPMSG_NS_DESTROY)
+ return -EINVAL;
+
+ strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
+ nsm.addr = cpu_to_le32(rpdev->ept->addr);
+ nsm.flags = cpu_to_le32(ns_flag);
+
+ return rpmsg_send_offchannel(rpdev->ept, RPMSG_NS_ADDR, RPMSG_NS_ADDR,
+, sizeof(nsm));
+}
+
+int rpmsg_ns_announce_create(struct rpmsg_device *rpdev)
+{
+ return rpmsg_ns_channel_announce(rpdev, RPMSG_NS_CREATE);
+}
+EXPORT_SYMBOL(rpmsg_ns_announce_create);
+
+int rpmsg_ns_announce_destroy(struct rpmsg_device *rpdev)
+{
+ return rpmsg_ns_channel_announce(rpdev, RPMSG_NS_DESTROY);
+}
+EXPORT_SYMBOL(rpmsg_ns_announce_destroy);
+
/* Invoked when a name service announcement arrives */
static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
void *priv, u32 src)
--
2.17.1
[PATCH v2 6/8] rpmsg: virtio: use rpmsg ns device for the ns announcement
As generic NS driver is available, rely on it for NS management instead of
managing it in RPMsg virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/Kconfig| 1 +
drivers/rpmsg/virtio_rpmsg_bus.c | 86
2 files changed, 21 insertions(+), 66 deletions(-)
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index c3fc75e6514b..1394114782d2 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -71,5 +71,6 @@ config RPMSG_VIRTIO
depends on HAS_DMA
select RPMSG
select VIRTIO
+ select RPMSG_NS
endmenu
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index b2927661868c..f771fdae150e 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -48,7 +48,6 @@
* @endpoints_lock: lock of the endpoints set
* @sendq: wait queue of sending contexts waiting for a tx buffers
* @sleepers: number of senders that are waiting for a tx buffer
- * @ns_ept:the bus's name service endpoint
*
* This structure stores the rpmsg state of a given virtio remote processor
* device (there might be several virtio proc devices for each physical
@@ -67,7 +66,6 @@ struct virtproc_info {
struct mutex endpoints_lock;
wait_queue_head_t sendq;
atomic_t sleepers;
- struct rpmsg_endpoint *ns_ept;
};
/* The feature bitmap for virtio rpmsg */
@@ -841,68 +839,14 @@ static void rpmsg_xmit_done(struct virtqueue *svq)
wake_up_interruptible(>sendq);
}
-/* invoked when a name service announcement arrives */
-static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
- void *priv, u32 src)
-{
- struct rpmsg_ns_msg *msg = data;
- struct rpmsg_device *newch;
- struct rpmsg_channel_info chinfo;
- struct virtproc_info *vrp = priv;
- struct device *dev = >vdev->dev;
- int ret;
-
-#if defined(CONFIG_DYNAMIC_DEBUG)
- dynamic_hex_dump("NS announcement: ", DUMP_PREFIX_NONE, 16, 1,
-data, len, true);
-#endif
-
- if (len != sizeof(*msg)) {
- dev_err(dev, "malformed ns msg (%d)\n", len);
- return -EINVAL;
- }
-
- /*
-* the name service ept does _not_ belong to a real rpmsg channel,
-* and is handled by the rpmsg bus itself.
-* for sanity reasons, make sure a valid rpdev has _not_ sneaked
-* in somehow.
-*/
- if (rpdev) {
- dev_err(dev, "anomaly: ns ept has an rpdev handle\n");
- return -EINVAL;
- }
-
- /* don't trust the remote processor for null terminating the name */
- msg->name[RPMSG_NAME_SIZE - 1] = '\0';
-
- strncpy(chinfo.name, msg->name, sizeof(chinfo.name));
- chinfo.src = RPMSG_ADDR_ANY;
- chinfo.dst = virtio32_to_cpu(vrp->vdev, msg->addr);
-
- dev_info(dev, "%sing channel %s addr 0x%x\n",
-virtio32_to_cpu(vrp->vdev, msg->flags) & RPMSG_NS_DESTROY ?
-"destroy" : "creat", msg->name, chinfo.dst);
-
- if (virtio32_to_cpu(vrp->vdev, msg->flags) & RPMSG_NS_DESTROY) {
- ret = rpmsg_unregister_device(>vdev->dev, );
- if (ret)
- dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
- } else {
- newch = __rpmsg_create_channel(vrp, );
- if (!newch)
- dev_err(dev, "rpmsg_create_channel failed\n");
- }
-
- return 0;
-}
-
static int rpmsg_probe(struct virtio_device *vdev)
{
vq_callback_t *vq_cbs[] = { rpmsg_recv_done, rpmsg_xmit_done };
static const char * const names[] = { "input", "output" };
struct virtqueue *vqs[2];
struct virtproc_info *vrp;
+ struct virtio_rpmsg_channel *vch;
+ struct rpmsg_device *rpdev_ns;
void *bufs_va;
int err = 0, i;
size_t total_buf_space;
@@ -978,14 +922,27 @@ static int rpmsg_probe(struct virtio_device *vdev)
/* if supported by the remote processor, enable the name service */
if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS)) {
- /* a dedicated endpoint handles the name service msgs */
- vrp->ns_ept = __rpmsg_create_ept(vrp, NULL, rpmsg_ns_cb,
- vrp, RPMSG_NS_ADDR);
- if (!vrp->ns_ept) {
- dev_err(>dev, "failed to create the ns ept\n");
+ vch = kzalloc(sizeof(*vch), GFP_KERNEL);
+ if (!vch) {
err = -ENOMEM;
goto free_coherent;
}
+
+ /* Link the channel to our vrp */
+ vch->vrp = vrp;
+
+ /* Assign public information to the rpmsg_device */
+ rpdev_ns = >rpdev;
+ rpdev_ns->ops = _rpmsg_ops;
+
+ rpdev_ns->dev.parent = >vdev->dev;
+
[PATCH v2 3/8] rpmsg: virtio: add rpmsg channel device ops
Implement the create and release of the RPMsg channel
for the RPMsg virtio bus.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 736bc7b9dea8..910d30818901 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -176,6 +176,12 @@ static int virtio_rpmsg_trysendto(struct rpmsg_endpoint
*ept, void *data,
int len, u32 dst);
static int virtio_rpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src,
u32 dst, void *data, int len);
+static struct rpmsg_device *
+ virtio_rpmsg_create_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
+static int virtio_rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo);
+
static const struct rpmsg_endpoint_ops virtio_endpoint_ops = {
.destroy_ept = virtio_rpmsg_destroy_ept,
@@ -372,6 +378,8 @@ static int virtio_rpmsg_announce_destroy(struct
rpmsg_device *rpdev)
}
static const struct rpmsg_device_ops virtio_rpmsg_ops = {
+ .create_channel = virtio_rpmsg_create_channel,
+ .release_channel = virtio_rpmsg_release_channel,
.create_ept = virtio_rpmsg_create_ept,
.announce_create = virtio_rpmsg_announce_create,
.announce_destroy = virtio_rpmsg_announce_destroy,
@@ -439,6 +447,25 @@ __rpmsg_create_channel(struct virtproc_info *vrp,
return rpdev;
}
+static struct rpmsg_device *
+ virtio_rpmsg_create_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
+ struct virtproc_info *vrp = vch->vrp;
+
+ return __rpmsg_create_channel(vrp, chinfo);
+}
+
+static int virtio_rpmsg_release_channel(struct rpmsg_device *rpdev,
+ struct rpmsg_channel_info *chinfo)
+{
+ struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
+ struct virtproc_info *vrp = vch->vrp;
+
+ return rpmsg_unregister_device(>vdev->dev, chinfo);
+}
+
/* super simple buffer "allocator" that is just enough for now */
static void *get_a_tx_buf(struct virtproc_info *vrp)
{
--
2.17.1
[PATCH v2 5/8] rpmsg: introduce reserved rpmsg driver for ns announcement
The name service announcement should not be linked to the RPMsg virtio bus
but to the RPMsg protocol itself.
This patch proposes to break the dependency with the RPmsg virtio bus by
the introduction of the reserved RPMsg name service driver which will be in
charge of managing the RPMsg name service announcement.
This first patch only implements the probe and the RPMsg endpoint to
manage create and release channels remote requests.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/Kconfig | 8 ++
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/rpmsg_internal.h | 17 +
drivers/rpmsg/rpmsg_ns.c | 135 +
4 files changed, 161 insertions(+)
create mode 100644 drivers/rpmsg/rpmsg_ns.c
diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f96716893c2a..c3fc75e6514b 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -15,6 +15,14 @@ config RPMSG_CHAR
in /dev. They make it possible for user-space programs to send and
receive rpmsg packets.
+config RPMSG_NS
+ tristate "RPMSG name service announcement"
+ depends on RPMSG
+ help
+ Say Y here to enable the support of the name service announcement
+ channel that probes the associated RPMsg device on remote endpoint
+ service announcement.
+
config RPMSG_MTK_SCP
tristate "MediaTek SCP"
depends on MTK_SCP
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ffe932ef6050..8d452656f0ee 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_RPMSG)+= rpmsg_core.o
obj-$(CONFIG_RPMSG_CHAR) += rpmsg_char.o
+obj-$(CONFIG_RPMSG_NS) += rpmsg_ns.o
obj-$(CONFIG_RPMSG_MTK_SCP)+= mtk_rpmsg.o
qcom_glink-objs:= qcom_glink_native.o qcom_glink_ssr.o
obj-$(CONFIG_RPMSG_QCOM_GLINK) += qcom_glink.o
diff --git a/drivers/rpmsg/rpmsg_internal.h b/drivers/rpmsg/rpmsg_internal.h
index d5ab286d0e5e..641b48f6bf2a 100644
--- a/drivers/rpmsg/rpmsg_internal.h
+++ b/drivers/rpmsg/rpmsg_internal.h
@@ -102,4 +102,21 @@ static inline int rpmsg_chrdev_register_device(struct
rpmsg_device *rpdev)
return rpmsg_register_device(rpdev);
}
+/**
+ * rpmsg_ns_register_device() - register name service device based on rpdev
+ * @rpdev: prepared rpdev to be used for creating endpoints
+ *
+ * This function wraps rpmsg_register_device() preparing the rpdev for use as
+ * basis for the rpmsg name service device.
+ */
+static inline int rpmsg_ns_register_device(struct rpmsg_device *rpdev)
+{
+ strcpy(rpdev->id.name, "rpmsg_ns");
+ rpdev->driver_override = "rpmsg_ns";
+ rpdev->src = RPMSG_NS_ADDR;
+ rpdev->dst = RPMSG_NS_ADDR;
+
+ return rpmsg_register_device(rpdev);
+}
+
#endif
diff --git a/drivers/rpmsg/rpmsg_ns.c b/drivers/rpmsg/rpmsg_ns.c
new file mode 100644
index ..3c929b6976a6
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_ns.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) STMicroelectronics 2020 - All Rights Reserved
+ */
+#include
+#include
+#include
+#include
+#include "rpmsg_internal.h"
+
+/**
+ * enum rpmsg_ns_flags - dynamic name service announcement flags
+ *
+ * @RPMSG_NS_CREATE: a new remote service was just created
+ * @RPMSG_NS_DESTROY: a known remote service was just destroyed
+ */
+enum rpmsg_ns_flags {
+ RPMSG_NS_CREATE = 0,
+ RPMSG_NS_DESTROY= 1,
+};
+
+/**
+ * struct rpmsg_ns_msg - dynamic name service announcement message
+ * @name: name of remote service that is published
+ * @addr: address of remote service that is published
+ * @flags: indicates whether service is created or destroyed
+ *
+ * This message is sent across to publish a new service, or announce
+ * about its removal. When we receive these messages, an appropriate
+ * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
+ * or ->remove() handler of the appropriate rpmsg driver will be invoked
+ * (if/as-soon-as one is registered).
+ */
+struct rpmsg_ns_msg {
+ char name[RPMSG_NAME_SIZE];
+ __le32 addr;
+ __le32 flags;
+} __packed;
+
+/* Invoked when a name service announcement arrives */
+static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void *data, int len,
+ void *priv, u32 src)
+{
+ struct rpmsg_ns_msg *msg = data;
+ struct rpmsg_device *newch;
+ struct rpmsg_channel_info chinfo;
+ struct device *dev = >dev;
+ unsigned int flags = le32_to_cpu(msg->flags);
+ int ret;
+
+#if defined(CONFIG_DYNAMIC_DEBUG)
+ dynamic_hex_dump("NS announcement: ", DUMP_PREFIX_NONE, 16, 1,
+data, len, true);
+#endif
+
+ if (len != sizeof(*msg)) {
+ dev_err(dev, "malformed ns msg (%d)\n", len);
+ return -EINVAL;
+ }
+
+ /* Don't trust the remote processor for null
[PATCH v2 1/8] rpmsg: virtio: rename rpmsg_create_channel
Rename the internal function as it is internal, and as
the name will be used in rpmsg_core.
Signed-off-by: Arnaud Pouliquen
---
drivers/rpmsg/virtio_rpmsg_bus.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 9006fc7f73d0..736bc7b9dea8 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -390,8 +390,9 @@ static void virtio_rpmsg_release_device(struct device *dev)
* this function will be used to create both static and dynamic
* channels.
*/
-static struct rpmsg_device *rpmsg_create_channel(struct virtproc_info *vrp,
-struct rpmsg_channel_info
*chinfo)
+static struct rpmsg_device *
+__rpmsg_create_channel(struct virtproc_info *vrp,
+ struct rpmsg_channel_info *chinfo)
{
struct virtio_rpmsg_channel *vch;
struct rpmsg_device *rpdev;
@@ -864,7 +865,7 @@ static int rpmsg_ns_cb(struct rpmsg_device *rpdev, void
*data, int len,
if (ret)
dev_err(dev, "rpmsg_destroy_channel failed: %d\n", ret);
} else {
- newch = rpmsg_create_channel(vrp, );
+ newch = __rpmsg_create_channel(vrp, );
if (!newch)
dev_err(dev, "rpmsg_create_channel failed\n");
}
--
2.17.1
Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps
On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to throw an exception on driver
> > init, at least on my ThinkPad P72:
> >
> > nouveau :01:00.0: disp: chid 0 mthd 008c data 508c 102b
> >
> > This is magic nvidia speak for "You need to have the DMA notifier offset
> > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > this by doing that, and also perform an update afterwards to prevent
> > racing with the GPU when reading capabilities.
> >
> > Changes since v1:
> > * Don't just program the DMA notifier offset, make sure to actually
> > perform an update
> I'm not sure there's a need to send an Update() method here, I believe
> GetCapabilities() is an action method on its own right?
>
I'm not entirely sure about this part tbh. I do know that we need to call
GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
assumption was that if GetCapabilities() requires a DMA notifier offset to store
its results in, we'd probably want to fire an update or something to make sure
that we're not reading before it finishes writing capabilities?
> Ben.
>
> > Signed-off-by: Lyude Paul
> > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP
> > interlacing support")
> > Cc: # v5.8+
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 -
> > 1 file changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > index e341f572c2696..5e86feec3b720 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
> > int
> > core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> > {
> > - u32 *push = evo_wait(>core->chan, 2);
> > + struct nv50_core *core = disp->core;
> > + u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > + u32 *push;
> >
> > - if (push) {
> > - evo_mthd(push, 0x008c, 1);
> > - evo_data(push, 0x0);
> > - evo_kick(push, >core->chan);
> > - }
> > + core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > +
> > + push = evo_wait(>chan, 4);
> > + if (!push)
> > + return 0;
> > +
> > + evo_mthd(push, 0x0084, 1);
> > + evo_data(push, 0x8000 | NV50_DISP_CORE_NTFY);
> > + evo_mthd(push, 0x008c, 1);
> > + evo_data(push, 0x0);
> > + evo_kick(push, >chan);
> > +
> > + core->func->update(core, interlock, false);
> > + if (core->func->ntfy_wait_done(disp->sync, NV50_DISP_CORE_NTFY,
> > + core->chan.base.device))
> > + NV_ERROR(drm, "core notifier timeout\n");
> >
> > return 0;
> > }
> > --
> > 2.26.2
> >
> > ___
> > Nouveau mailing list
> > nouv...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Sincerely,
Lyude Paul (she/her)
Software Engineer at Red Hat
Re: TDX #VE in SYSCALL gap (was: [RFD] x86: Curing the exception and syscall trainwreck in hardware)
On Mon, Aug 24, 2020 at 9:40 PM Sean Christopherson wrote: > > +Andy > > On Mon, Aug 24, 2020 at 02:52:01PM +0100, Andrew Cooper wrote: > > And to help with coordination, here is something prepared (slightly) > > earlier. > > > > https://docs.google.com/document/d/1hWejnyDkjRRAW-JEsRjA5c9CKLOPc6VKJQsuvODlQEI/edit?usp=sharing > > > > This identifies the problems from software's perspective, along with > > proposing behaviour which ought to resolve the issues. > > > > It is still a work-in-progress. The #VE section still needs updating in > > light of the publication of the recent TDX spec. > > For #VE on memory accesses in the SYSCALL gap (or NMI entry), is this > something we (Linux) as the guest kernel actually want to handle gracefully > (where gracefully means not panicking)? For TDX, a #VE in the SYSCALL gap > would require one of two things: > > a) The guest kernel to not accept/validate the GPA->HPA mapping for the > relevant pages, e.g. code or scratch data. > > b) The host VMM to remap the GPA (making the GPA->HPA pending again). > > (a) is only possible if there's a fatal buggy guest kernel (or perhaps vBIOS). > (b) requires either a buggy or malicious host VMM. > > I ask because, if the answer is "no, panic at will", then we shouldn't need > to burn an IST for TDX #VE. Exceptions won't morph to #VE and hitting an > instruction based #VE in the SYSCALL gap would be a CPU bug or a kernel bug. Or malicious hypervisor action, and that's a problem. Suppose the hypervisor remaps a GPA used in the SYSCALL gap (e.g. the actual SYSCALL text or the first memory it accesses -- I don't have a TDX spec so I don't know the details). The user does SYSCALL, the kernel hits the funny GPA, and #VE is delivered. The microcode wil write the IRET frame, with mostly user-controlled contents, wherever RSP points, and RSP is also user controlled. Calling this a "panic" is charitable -- it's really game over against an attacker who is moderately clever. The kernel can't do anything about this because it's game over before the kernel has had the chance to execute any instructions.
Re: [PATCH 15/16] vc_screen: extract vcs_read_buf_header
Hi all,
Link:
https://syzkaller.appspot.com/bug?id=f332576321998d36cd07d09c9c1268cfed1895c9
As reported by syzbot, vcs_read_buf() is overflowing `con_buf16`, since
this patch removed the following check:
- if (count > CON_BUF_SIZE) {
- count = CON_BUF_SIZE;
- filled = count - pos;
- }
Decreasing `count` by `min(HEADER_SIZE - pos, count)` bypasses this check.
Additionally, this patch also removed updates to `skip` and `filled`.
What should we do in order to fix it?
Thank you,
Peilin Ye
Re: [PATCH] IB/qib: remove superfluous fallthrough statements
On Tue, 2020-08-25 at 11:49 -0500, Gustavo A. R. Silva wrote:
>
> On 8/25/20 11:26, Joe Perches wrote:
> > On Tue, 2020-08-25 at 11:19 -0500, Gustavo A. R. Silva wrote:
> > > On 8/25/20 10:51, Alex Dewar wrote:
> > > > Commit 36a8f01cd24b ("IB/qib: Add congestion control agent
> > > > implementation")
> > > > erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
> > > > were later converted to fallthrough statements by commit df561f6688fe
> > > > ("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
> > > > warning about unreachable code.
> > > >
> > > > Remove the fallthrough statements and replace the mass of gotos with
> > > > simple return statements to make the code terser and less bug-prone.
> > > >
> > >
> > > This should be split up into two separate patches: one to address the
> > > fallthrough markings, and another one for the gotos.
> >
> > I don't think it's necessary to break this into multiple patches.
> > Logical changes in a single patch are just fine, micro patches
> > aren't that useful.
> >
>
> There is a reason for this. Read the changelog text and review the patch.
What makes you think I didn't already do that?
I think your desire for micropatches is unnecessary.
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: sun8i: r40: Use sigma delta modulation for audio PLL
On Wed, Aug 26, 2020 at 12:45 AM Jernej Škrabec wrote:
>
> Dne torek, 25. avgust 2020 ob 16:46:31 CEST je Chen-Yu Tsai napisal(a):
> > On Tue, Aug 25, 2020 at 9:11 PM Jernej Skrabec
> wrote:
> > > Audio cores need specific clock rates which can't be simply obtained by
> > > adjusting integer multipliers and dividers. HW for such cases supports
> > > delta-sigma modulation which enables fractional multipliers.
> > >
> > > Port H3 delta-sigma table to R40. They have identical audio PLLs.
> > >
> > > Signed-off-by: Jernej Skrabec
> > > ---
> > >
> > > drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 37 ++--
> > > 1 file changed, 24 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > > b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c index 23bfe1d12f21..84153418453f
> > > 100644
> > > --- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > > +++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > > @@ -45,18 +45,29 @@ static struct ccu_nkmp pll_cpu_clk = {
> > >
> > > * the base (2x, 4x and 8x), and one variable divider (the one true
> > > * pll audio).
> > > *
> > >
> > > - * We don't have any need for the variable divider for now, so we just
> > > - * hardcode it to match with the clock names
> > > + * With sigma-delta modulation for fractional-N on the audio PLL,
> > > + * we have to use specific dividers. This means the variable divider
> > > + * can no longer be used, as the audio codec requests the exact clock
> > > + * rates we support through this mechanism. So we now hard code the
> > > + * variable divider to 1. This means the clock rates will no longer
> > > + * match the clock names.
> > >
> > > */
> > >
> > > #define SUN8I_R40_PLL_AUDIO_REG0x008
> > >
> > > -static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> > > - "osc24M", 0x008,
> > > - 8, 7,/* N */
> > > - 0, 5,/* M */
> > > - BIT(31), /* gate */
> > > - BIT(28), /* lock */
> > > - CLK_SET_RATE_UNGATE);
> > > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > > + { .rate = 22579200, .pattern = 0xc0010d84, .m = 8, .n = 7 },
> > > + { .rate = 24576000, .pattern = 0xc000ac02, .m = 14, .n = 14 },
> >
> > The user manual has an additional requirement: 3 <= N/M <= 21.
> > Though it then says 72 <= 24*N/P <= 504. Not sure which one is
> > right...
> >
> > Did you run into any glitches or audio distortions?
>
> No, I tested HDMI audio and it seems to work fine.
>
> BSP driver also uses those values:
> https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
> clk/sunxi/clk-sun8iw11.c#L160
Sounds good. Thanks.
Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on a 64 bit system
On Tue, Aug 25, 2020 at 9:32 AM Kyle Huey wrote:
>
> On Tue, Aug 25, 2020 at 9:12 AM Andy Lutomirski wrote:
> > I don’t like this at all. Your behavior really shouldn’t depend on
> > whether the new instructions are available. Also, some day I would
> > like to change Linux to have the new behavior even if FSGSBASE
> > instructions are not available, and this will break rr again. (The
> > current !FSGSBASE behavior is an ugly optimization of dubious value.
> > I would not go so far as to describe it as correct.)
>
> Ok.
>
> > I would suggest you do one of the following things:
> >
> > 1. Use int $0x80 directly to load 32-bit regs into a child. This
> > might dramatically simplify your code and should just do the right
> > thing.
>
> I don't know what that means.
This is untested, but what I mean is:
static int ptrace32(int req, pid_t pid, int addr, int data) {
int ret;
/* new enough kernels won't clobber r8, etc. */
asm volatile ("int $0x80" : "=a" (ret) : "a" (26 /* ptrace */), "b"
(req), "c" (pid), "d" (addr), "S" (data) : "flags", "r8", "r9", "r10",
"r11");
return ret;
}
with a handful of caveats:
- This won't compile with -fPIC, I think. Instead you'll need to
write a little bit of asm to set up and restore ebx yourself. gcc is
silly like this.
- Note that addr is an int. You'll need to mmap(..., MAP_32BIT, ...)
to get a buffer that can be pointed to with an int.
The advantage is that this should work on all kernels that support
32-bit mode at all.
>
> > 2. Something like your patch but make it unconditional.
> >
> > 3. Ask for, and receive, real kernel support for setting FS and GS in
> > the way that 32-bit code expects.
>
> I think the easiest way forward for us would be a PTRACE_GET/SETREGSET
> like operation that operates on the regsets according to the
> *tracee*'s bitness (rather than the tracer, as it works currently).
> Does that sound workable?
>
Strictly speaking, on Linux, there is no unified concept of a task's
bitness, so "set all these registers according to the target's
bitness" is not well defined. We could easily give you a
PTRACE_SETREGS_X86_32, etc, though.
[PATCH] VMCI: check return value of get_user_pages_fast() for errors
In a couple of places in qp_host_get_user_memory(),
get_user_pages_fast() is called without properly checking for errors. If
e.g. -EFAULT is returned, this negative value will then be passed on to
qp_release_pages(), which expects a u64 as input.
Fix this by only calling qp_release_pages() when we have a positive
number returned.
Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.")
Signed-off-by: Alex Dewar
---
drivers/misc/vmw_vmci/vmci_queue_pair.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/vmw_vmci/vmci_queue_pair.c
b/drivers/misc/vmw_vmci/vmci_queue_pair.c
index 8531ae781195..c49065887e8f 100644
--- a/drivers/misc/vmw_vmci/vmci_queue_pair.c
+++ b/drivers/misc/vmw_vmci/vmci_queue_pair.c
@@ -657,8 +657,9 @@ static int qp_host_get_user_memory(u64 produce_uva,
if (retval < (int)produce_q->kernel_if->num_pages) {
pr_debug("get_user_pages_fast(produce) failed (retval=%d)",
retval);
- qp_release_pages(produce_q->kernel_if->u.h.header_page,
-retval, false);
+ if (retval > 0)
+ qp_release_pages(produce_q->kernel_if->u.h.header_page,
+ retval, false);
err = VMCI_ERROR_NO_MEM;
goto out;
}
@@ -670,8 +671,9 @@ static int qp_host_get_user_memory(u64 produce_uva,
if (retval < (int)consume_q->kernel_if->num_pages) {
pr_debug("get_user_pages_fast(consume) failed (retval=%d)",
retval);
- qp_release_pages(consume_q->kernel_if->u.h.header_page,
-retval, false);
+ if (retval > 0)
+ qp_release_pages(consume_q->kernel_if->u.h.header_page,
+ retval, false);
qp_release_pages(produce_q->kernel_if->u.h.header_page,
produce_q->kernel_if->num_pages, false);
err = VMCI_ERROR_NO_MEM;
--
2.28.0
Re: [linux-sunxi] [PATCH] clk: sunxi-ng: sun8i: r40: Use sigma delta modulation for audio PLL
Dne torek, 25. avgust 2020 ob 16:46:31 CEST je Chen-Yu Tsai napisal(a):
> On Tue, Aug 25, 2020 at 9:11 PM Jernej Skrabec
wrote:
> > Audio cores need specific clock rates which can't be simply obtained by
> > adjusting integer multipliers and dividers. HW for such cases supports
> > delta-sigma modulation which enables fractional multipliers.
> >
> > Port H3 delta-sigma table to R40. They have identical audio PLLs.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/clk/sunxi-ng/ccu-sun8i-r40.c | 37 ++--
> > 1 file changed, 24 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c index 23bfe1d12f21..84153418453f
> > 100644
> > --- a/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > +++ b/drivers/clk/sunxi-ng/ccu-sun8i-r40.c
> > @@ -45,18 +45,29 @@ static struct ccu_nkmp pll_cpu_clk = {
> >
> > * the base (2x, 4x and 8x), and one variable divider (the one true
> > * pll audio).
> > *
> >
> > - * We don't have any need for the variable divider for now, so we just
> > - * hardcode it to match with the clock names
> > + * With sigma-delta modulation for fractional-N on the audio PLL,
> > + * we have to use specific dividers. This means the variable divider
> > + * can no longer be used, as the audio codec requests the exact clock
> > + * rates we support through this mechanism. So we now hard code the
> > + * variable divider to 1. This means the clock rates will no longer
> > + * match the clock names.
> >
> > */
> >
> > #define SUN8I_R40_PLL_AUDIO_REG0x008
> >
> > -static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_audio_base_clk, "pll-audio-base",
> > - "osc24M", 0x008,
> > - 8, 7,/* N */
> > - 0, 5,/* M */
> > - BIT(31), /* gate */
> > - BIT(28), /* lock */
> > - CLK_SET_RATE_UNGATE);
> > +static struct ccu_sdm_setting pll_audio_sdm_table[] = {
> > + { .rate = 22579200, .pattern = 0xc0010d84, .m = 8, .n = 7 },
> > + { .rate = 24576000, .pattern = 0xc000ac02, .m = 14, .n = 14 },
>
> The user manual has an additional requirement: 3 <= N/M <= 21.
> Though it then says 72 <= 24*N/P <= 504. Not sure which one is
> right...
>
> Did you run into any glitches or audio distortions?
No, I tested HDMI audio and it seems to work fine.
BSP driver also uses those values:
https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/blob/master/linux-sunxi/drivers/
clk/sunxi/clk-sun8iw11.c#L160
Best regards,
Jernej
Re: [net-next v5 1/2] seg6: inherit DSCP of inner IPv4 packets
On 8/25/20 10:02 AM, Ahmed Abdelsalam wrote: > This patch allows SRv6 encapsulation to inherit the DSCP value of > the inner IPv4 packet. > > This allows forwarding packet across the SRv6 fabric based on their > original traffic class. > > The option is controlled through a sysctl (seg6_inherit_inner_ipv4_dscp). > The sysctl has to be set to 1 to enable this feature. > rather than adding another sysctl, can this be done as a SEG6_LOCAL attribute and managed via seg6_local_lwt?
Re: [PATCH v36 11/24] x86/sgx: Add SGX enclave driver
On Thu, Jul 16, 2020 at 04:52:50PM +0300, Jarkko Sakkinen wrote:
Just minor things below - I'm not even going to pretend I fully
understand what's going on but FWICT, it looks non-threateningly ok to
me.
> diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> b/arch/x86/kernel/cpu/sgx/driver.c
> new file mode 100644
> index ..b52520407f5b
> --- /dev/null
> +++ b/arch/x86/kernel/cpu/sgx/driver.c
> @@ -0,0 +1,177 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +// Copyright(c) 2016-18 Intel Corporation.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "driver.h"
> +#include "encl.h"
> +
> +MODULE_DESCRIPTION("Intel SGX Enclave Driver");
> +MODULE_AUTHOR("Jarkko Sakkinen ");
> +MODULE_LICENSE("Dual BSD/GPL");
That boilerplate stuff usually goes to the end of the file.
...
> +static struct sgx_encl_page *sgx_encl_load_page(struct sgx_encl *encl,
> + unsigned long addr)
> +{
> + struct sgx_encl_page *entry;
> + unsigned int flags;
> +
> + /* If process was forked, VMA is still there but vm_private_data is set
> + * to NULL.
> + */
> + if (!encl)
> + return ERR_PTR(-EFAULT);
> +
> + flags = atomic_read(>flags);
> +
^ Superfluous newline.
> + if ((flags & SGX_ENCL_DEAD) || !(flags & SGX_ENCL_INITIALIZED))
> + return ERR_PTR(-EFAULT);
> +
> + entry = xa_load(>page_array, PFN_DOWN(addr));
> + if (!entry)
> + return ERR_PTR(-EFAULT);
> +
> + /* Page is already resident in the EPC. */
> + if (entry->epc_page)
> + return entry;
> +
> + return ERR_PTR(-EFAULT);
> +}
> +
> +static void sgx_mmu_notifier_release(struct mmu_notifier *mn,
> + struct mm_struct *mm)
> +{
> + struct sgx_encl_mm *encl_mm =
> + container_of(mn, struct sgx_encl_mm, mmu_notifier);
Just let it stick out.
> + struct sgx_encl_mm *tmp = NULL;
> +
> + /*
> + * The enclave itself can remove encl_mm. Note, objects can't be moved
> + * off an RCU protected list, but deletion is ok.
> + */
> + spin_lock(_mm->encl->mm_lock);
> + list_for_each_entry(tmp, _mm->encl->mm_list, list) {
> + if (tmp == encl_mm) {
> + list_del_rcu(_mm->list);
> + break;
> + }
> + }
> + spin_unlock(_mm->encl->mm_lock);
> +
> + if (tmp == encl_mm) {
> + synchronize_srcu(_mm->encl->srcu);
> + mmu_notifier_put(mn);
> + }
> +}
> +
> +static void sgx_mmu_notifier_free(struct mmu_notifier *mn)
> +{
> + struct sgx_encl_mm *encl_mm =
> + container_of(mn, struct sgx_encl_mm, mmu_notifier);
Ditto.
...
> +/**
> + * sgx_encl_may_map() - Check if a requested VMA mapping is allowed
> + * @encl:an enclave
> + * @start: lower bound of the address range, inclusive
> + * @end: upper bound of the address range, exclusive
> + * @vm_prot_bits:requested protections of the address range
> + *
> + * Iterate through the enclave pages contained within [@start, @end) to
> verify
> + * the permissions requested by @vm_prot_bits do not exceed that of any
> enclave
> + * page to be mapped.
> + *
> + * Return:
> + * 0 on success,
> + * -EACCES if VMA permissions exceed enclave page permissions
> + */
> +int sgx_encl_may_map(struct sgx_encl *encl, unsigned long start,
> + unsigned long end, unsigned long vm_flags)
> +{
> + unsigned long vm_prot_bits = vm_flags & (VM_READ | VM_WRITE | VM_EXEC);
> + unsigned long idx_start = PFN_DOWN(start);
> + unsigned long idx_end = PFN_DOWN(end - 1);
> + struct sgx_encl_page *page;
> + XA_STATE(xas, >page_array, idx_start);
> +
> + /*
> + * Disallow RIE tasks as their VMA permissions might conflict with the
"RIE", hmm what is that?
/me looks at the test
Aaah, READ_IMPLIES_EXEC. Is "RIE" some widely accepted acronym I'm not
aware of?
> + * enclave page permissions.
> + */
> + if (!!(current->personality & READ_IMPLIES_EXEC))
The "!!" is not really needed - you're in boolean context.
...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
RE: [LKP] Re: [x86/mce] 1de08dccd3: will-it-scale.per_process_ops -14.1% regression
> These 2 variables are accessed in 2 hot call stacks (for this 288 CPU > Xeon Phi platform): This might be the key element of "weirdness" for this system. It has 288 CPUs ... cache alignment problems are often not too bad on "small" systems. The as you scale up to bigger machines you suddenly hit some critical point and performance drops dramatically. It's good that you are picking up tips on how to bisect these and diagnose the underlying problem. Number of cores is going to keep increasing, so we will keep finding new issues like this. -Tony
Re: [PATCH] IB/qib: remove superfluous fallthrough statements
On 8/25/20 11:26, Joe Perches wrote:
> On Tue, 2020-08-25 at 11:19 -0500, Gustavo A. R. Silva wrote:
>>
>> On 8/25/20 10:51, Alex Dewar wrote:
>>> Commit 36a8f01cd24b ("IB/qib: Add congestion control agent implementation")
>>> erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
>>> were later converted to fallthrough statements by commit df561f6688fe
>>> ("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
>>> warning about unreachable code.
>>>
>>> Remove the fallthrough statements and replace the mass of gotos with
>>> simple return statements to make the code terser and less bug-prone.
>>>
>>
>> This should be split up into two separate patches: one to address the
>> fallthrough markings, and another one for the gotos.
>
> I don't think it's necessary to break this into multiple patches.
> Logical changes in a single patch are just fine, micro patches
> aren't that useful.
>
There is a reason for this. Read the changelog text and review the patch.
Thanks
--
Gustavo
Re: [PATCH v3] perf parse-events: Set exclude_guest=1 for user-space counting
Em Tue, Aug 25, 2020 at 03:54:37PM +0800, Jin, Yao escreveu: > Hi Arnaldo, > > On 8/19/2020 11:05 AM, Like Xu wrote: > > Hi Arnaldo, > > > > On 2020/8/17 10:32, Jin, Yao wrote: > > > Hi Arnaldo, > > > > > > On 8/14/2020 8:47 PM, Arnaldo Carvalho de Melo wrote: > > > > Em Fri, Aug 14, 2020 at 09:21:20AM +0800, Jin Yao escreveu: > > > > > Currently if we run 'perf record -e cycles:u', exclude_guest=0. > > > > > > > > > > But it doesn't make sense in most cases that we request for > > > > > user-space counting but we also get the guest report. > > > > > > > > > > Of course, we also need to consider perf kvm usage case that > > > > > authorized perf users on the host may only want to count guest > > > > > user space events. For example, > > > > > > > > > > perf kvm --guest record -e cycles:u > > > > Ok, probably this works, but what if I want to record guest user samples > > > > without using 'perf kvm'? > > > > > > > > Can we have a 'U' modifier, perhaps, for that? > > > > > > > > I.e. > > > > > > > > perf record -e cycles:uU would not set exclude_host not exclude_guest, > > > > cycles:u excludes guest user, cycles:U excludes host user, would that be > > > > possible? > > > > > > > > Anyway, I think that with what we have, your patch makes sense, having a > > > > way to, without using 'perf kvm' still be able to sample the guest can > > > > be done on top. of this. > > > > > > > > Xu, can we get your Reviewed-by if this addresses your concerns? > > > > My concern is about do not break the perf kvm usages and Yao did it in v3. > > > > Tested-by: Like Xu > > > > Can this patch be accepted? Sure. > > > > > > > > - Arnaldo > > > > > > Do you suggest we will create a new modifier 'U' as a follow-up patch? > > > > > > cycles:u - Count host user space but it doesn't count the guest user > > > space (exclude_host = 0, exclude_guest = 1, exclude_kernel = 1, > > > exclude_user = 0, exclude_hv = 1) > > > > > > cycles:U - Count the guest user space but it doesn't count the host > > > user space (exclude_host = 1, exclude_guest = 0, exclude_kernel = 1, > > > exclude_user = 0, exclude_hv = 1) > > > > > > Is above understanding correct? > > > > Do we really need to support sample guests without using perf kvm? > > > > If it's true, I would prefer "cycles:uG" to cover guest user space > > events only, "cycles:kG" to cover guest kernel space events only, > > and only host events are sampled without the ":G" modifier by default. > > > > I am not sure if ":G" has been used in perf. > > > > That may be another good idea I think. :) I have to check, but I don't think that :G is used. - Arnaldo
RE: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
Hi Rob, > -Original Message- > From: Rob Herring > Sent: Tuesday, August 25, 2020 9:51 PM > To: Sagar Kadam > Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley ( > Sifive) ; Yash Shah ; > pal...@dabbelt.com; linux-kernel@vger.kernel.org; linux- > ri...@lists.infradead.org > Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings > to json-schema > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > On Tue, Aug 25, 2020 at 2:47 AM Sagar Kadam > wrote: > > > > Hello Rob, > > > > > -Original Message- > > > From: Rob Herring > > > Sent: Monday, August 24, 2020 11:06 PM > > > To: Sagar Kadam > > > Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley > > > ( > > > Sifive) ; robh...@kernel.org; Yash Shah > > > ; pal...@dabbelt.com; linux- > > > ker...@vger.kernel.org; linux-ri...@lists.infradead.org > > > Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: > > > convert bindings to json-schema > > > > > > [External Email] Do not click links or attachments unless you > > > recognize the sender and know the content is safe > > > > > > On Mon, 24 Aug 2020 13:20:21 +0530, Sagar Kadam wrote: > > > > Convert the device tree bindings for the SiFive's FU540-C000 SoC's > > > > L2 Cache controller to YAML format. > > > > > > > > Signed-off-by: Sagar Kadam > > > > --- > > > > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 > > > > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | > > > > 93 > > > > ++ > > > > 2 files changed, 93 insertions(+), 51 deletions(-) delete mode > > > > 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt > > > > create mode 100644 > > > > Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml > > > > > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > > > > I had checked using DT_SCHEMA_FILES option due to which it didn't > > catch any error on other schemas. Without this I could regenerate the > error you mentioned. > > I will fix it and update. Sorry for the error. > > Update your kernel. DT_SCHEMA_FILES setting no longer matters on current > tree. It only affects 'dtbs_check' now. > Thanks for the input. Sure, I see v5.9-rc2 as latest tag on mainline, I will base and fix my patch above it. BR, Sagar > Rob
Re: [PATCH] MAINTAINERS: add namespace entry
On Tue, Aug 25, 2020 at 11:26:07AM -0500, Eric W. Biederman wrote: > > A) If we are going to have this discussion in public we really should >include the containers list. Ah, just used the output from get_maintainers.pl. > > B) The challenge is that most of the namespace work has become part of >it's upstream subsystem so we really need to list the containers >list and ourselves as reviewers, more than maintainers who run >a tree for the code. > > C) You have overstated what I have agreed to here. >I have have previously said that I agree that having a MAINTAINERS >entry so people who are unfamiliar with the situation with namespaces >can find us. Given that most of the changes going forward are likely >to be maintenance changes. > >I also said we need to talk about how we plan to maintain the code >here. > >It feels like you are pushing this hard, and I am not certain why you >are pushing and rushing this. With my maintainer hat on my big >concern is we catch the issues that will introduce security issue. >Recently I have seen a report that there is an issue on Ubuntu >kernels where anyone can read /etc/shadow. The problem is that >Ubuntu has not been cautions and has not taken the time to figure out >how to enable things for unprivileged users safely, and have just >enabled the code to be used by unprivileged users because it is >useful. > >In combination with you pushing hard and not taking the time to >complete this conversation in private with me, this MAINTAINERS entry >makes me uneasy as it feels like you may be looking for a way to push >the code into the mainline kernel like has been pushed into the >Ubuntu kernel. I may be completely wrong I just don't know what to >make of your not finishing our conversation in private, and forcing >my hand by posting this patch publicly. > > The files you have listed are reasonable for a maintainers entry as they > have no other maintainers. > > I know I have been less active after the birth of my young son, and I > know the practical rule is that the person who does the work is the > maintainer. At the same time I am not convinced you are actually going > to do the work to make new code maintainable and not a problem for other > kernel developers. > > A big part the job over the years has been to make the namespace ideas > proposed sane, and to keep the burden from other maintainers of naive > and terrible code. Pushing this change before we finished our private > conversation makes me very nervous on that front. Ok, Eric. I've tried to do this with the best intentions possible and I would assume that this is the default assumption everyone would have after all these years. This type of response is very shocking to me and I honestly don't know how to respond! I'm dropping this completely because I'm not going to be accused of having a hidden agenda! Such an accusation is imho completely out of line and it is completely unacceptable to treat a peer like this! Christian
Re: [PATCH V3 2/3] arm64: dts: qcom: sc7180: Add sleep pin ctrl for BT uart
On Tue, Aug 25, 2020 at 06:42:28PM +0530, ska...@codeaurora.org wrote:
> On 2020-08-21 22:52, Matthias Kaehlcke wrote:
> > On Thu, Aug 20, 2020 at 07:21:06PM +0530, satya priya wrote:
> > > Add sleep pin ctrl for BT uart, and also change the bias
> > > configuration to match Bluetooth module.
> > >
> > > Signed-off-by: satya priya
> > > Reviewed-by: Akash Asthana
> > > ---
> > > Changes in V2:
> > > - This patch adds sleep state for BT UART. Newly added in V2.
> > >
> > > Changes in V3:
> > > - Remove "output-high" for TX from both sleep and default states
> > >as it is not required. Configure pull-up for TX in sleep state.
> > >
> > > arch/arm64/boot/dts/qcom/sc7180-idp.dts | 54
> > > +++--
> > > 1 file changed, 45 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > > b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > > index d8b5507..806f626 100644
> > > --- a/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > > +++ b/arch/arm64/boot/dts/qcom/sc7180-idp.dts
> > > @@ -473,20 +473,20 @@
> > >
> > > _uart3_default {
> > > pinconf-cts {
> > > - /*
> > > - * Configure a pull-down on 38 (CTS) to match the pull of
> > > - * the Bluetooth module.
> > > - */
> > > + /* Configure no pull on 38 (CTS) to match Bluetooth module */
> > > pins = "gpio38";
> > > - bias-pull-down;
> > > - output-high;
> > > + bias-disable;
> >
> > I think it should be ok in functional terms, but I don't like the
> > rationale
> > and also doubt the change is really needed.
> >
> > If the pull is removed to match the Bluetooth module, then that sounds
> > as
> > if the signal was floating on the the BT side, which I think is not the
> > case.
> > Yes, according to the datasheet there is no pull when the BT controller
> > is
> > active, but then it drives the signal actively to either high or low.
> > There
> > seems to be no merit in 'matching' the Bluetooth side in this case, if
> > the
> > signal was really floating on the BT side we would definitely not want
> > this.
> >
> > In a reply to v2 you said:
> >
> > > Recently on cherokee we worked with BT team and came to an agreement
> > > to
> > > keep no-pull from our side in order to not conflict with their pull in
> > > any state.
> >
> > What are these conflicting pull states?
> >
> > The WCN3998 datasheet has a pull-down on RTS (WCN3998 side) in reset and
> > boot mode, and no pull in active mode. In reset and boot mode the host
> > config with a pull down would match, and no pull in active mode doesn't
> > conflict with the pull-down on the host UART. My understanding is that
> > the pinconf pulls are weak pulls, so as soon as the BT chip drives its
> > RTS the pull on the host side shouldn't matter.
> >
>
> yes, I agree with you, the pinconf pulls are weak. As this is driven by BT
> SoC (pull on HOST side shouldn't matter), we are not mentioning any bias
> configuration from our side and simply putting it as no-pull, just to not
> conflict in any case. It seems that the rationale mentioned is a bit
> confusing i will change it to clearly specify why we are configuring
> no-pull.
>
> > Is this change actually related with wakeup support? I have the
> > impression
> > that multiple things are conflated in this patch. If some of the changes
> > are just fixing/improving other things they should be in a separate
> > patch,
> > which could be part of this series, otherwise it's really hard to
> > distinguish between the pieces that are actually relevant for wakeup and
> > the rest.
> >
> > Independently of whether the changes are done in a single or multiple
> > patches, the commit log should include details on why the changes are
> > necessary, especially when there are not explantatory comments in the
> > DT/code itself (e.g. the removal of 'output-high', which seems correct
> > to me, but no reason is given why it is done).
> >
>
> This change is not related to wakeup support, I will make it a separate
> patch, will also mention the details in commit text.
>
> > > };
> > >
> > > pinconf-rts {
> > > - /* We'll drive 39 (RTS), so no pull */
> > > + /*
> > > + * Configure pull-down on 39 (RTS). This is needed to avoid a
> > > + * floating pin which could mislead Bluetooth controller
> > > + * with UART RFR state (READY/NOT_READY).
> > > + */
> > > pins = "gpio39";
> > > drive-strength = <2>;
> > > - bias-disable;
> > > + bias-pull-down;
> > > };
> >
> > [copy of my comment on v2]
> >
> > I'm a bit at a loss here, about two things:
> >
> > RTS is an output pin controlled by the UART. IIUC if the UART port is
> > active
> > and hardware flow control is enabled the RTS signal is either driven to
> > high
> > or low, but not floating.
>
> Yes, RTS is either driven high or low. HW flow control is always enabled and
> only
Re: [PATCH v2 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary
Suren Baghdasaryan writes:
> Currently __set_oom_adj loops through all processes in the system to
> keep oom_score_adj and oom_score_adj_min in sync between processes
> sharing their mm. This is done for any task with more that one mm_users,
> which includes processes with multiple threads (sharing mm and signals).
> However for such processes the loop is unnecessary because their signal
> structure is shared as well.
> Android updates oom_score_adj whenever a tasks changes its role
> (background/foreground/...) or binds to/unbinds from a service, making
> it more/less important. Such operation can happen frequently.
> We noticed that updates to oom_score_adj became more expensive and after
> further investigation found out that the patch mentioned in "Fixes"
> introduced a regression. Using Pixel 4 with a typical Android workload,
> write time to oom_score_adj increased from ~3.57us to ~362us. Moreover
> this regression linearly depends on the number of multi-threaded
> processes running on the system.
> Mark the mm with a new MMF_PROC_SHARED flag bit when task is created with
> (CLONE_VM && !CLONE_THREAD && !CLONE_VFORK). Change __set_oom_adj to use
> MMF_PROC_SHARED instead of mm_users to decide whether oom_score_adj
> update should be synchronized between multiple processes. To prevent
> races between clone() and __set_oom_adj(), when oom_score_adj of the
> process being cloned might be modified from userspace, we use
> oom_adj_mutex. Its scope is changed to global and it is renamed into
> oom_adj_lock for naming consistency with oom_lock. The combination of
> (CLONE_VM && !CLONE_THREAD) is rarely used except for the case of vfork().
> To prevent performance regressions of vfork(), we skip taking oom_adj_lock
> and setting MMF_PROC_SHARED when CLONE_VFORK is specified. Clearing the
> MMF_PROC_SHARED flag (when the last process sharing the mm exits) is left
> out of this patch to keep it simple and because it is believed that this
> threading model is rare. Should there ever be a need for optimizing that
> case as well, it can be done by hooking into the exit path, likely
> following the mm_update_next_owner pattern.
> With the combination of (CLONE_VM && !CLONE_THREAD && !CLONE_VFORK) being
> quite rare, the regression is gone after the change is applied.
This patch still makes my head hurt.
The obvious wrong things I have mentioned below.
> Fixes: 44a70adec910 ("mm, oom_adj: make sure processes sharing mm have same
> view of oom_score_adj")
> Reported-by: Tim Murray
> Debugged-by: Minchan Kim
> Suggested-by: Michal Hocko
> Signed-off-by: Suren Baghdasaryan
> ---
>
> v2:
> - Implemented proposal from Michal Hocko in:
> https://lore.kernel.org/linux-fsdevel/20200820124109.gi5...@dhcp22.suse.cz/
> - Updated description to reflect the change
>
> v1:
> - https://lore.kernel.org/linux-mm/20200820002053.1424000-1-sur...@google.com/
>
> fs/proc/base.c | 7 +++
> include/linux/oom.h| 1 +
> include/linux/sched/coredump.h | 1 +
> kernel/fork.c | 21 +
> mm/oom_kill.c | 2 ++
> 5 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index 617db4e0faa0..cff1a58a236c 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -1055,7 +1055,6 @@ static ssize_t oom_adj_read(struct file *file, char
> __user *buf, size_t count,
>
> static int __set_oom_adj(struct file *file, int oom_adj, bool legacy)
> {
> - static DEFINE_MUTEX(oom_adj_mutex);
> struct mm_struct *mm = NULL;
> struct task_struct *task;
> int err = 0;
> @@ -1064,7 +1063,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> if (!task)
> return -ESRCH;
>
> - mutex_lock(_adj_mutex);
> + mutex_lock(_adj_lock);
> if (legacy) {
> if (oom_adj < task->signal->oom_score_adj &&
> !capable(CAP_SYS_RESOURCE)) {
> @@ -1095,7 +1094,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> struct task_struct *p = find_lock_task_mm(task);
>
> if (p) {
> - if (atomic_read(>mm->mm_users) > 1) {
> + if (test_bit(MMF_PROC_SHARED, >mm->flags)) {
> mm = p->mm;
> mmgrab(mm);
> }
> @@ -1132,7 +1131,7 @@ static int __set_oom_adj(struct file *file, int
> oom_adj, bool legacy)
> mmdrop(mm);
> }
> err_unlock:
> - mutex_unlock(_adj_mutex);
> + mutex_unlock(_adj_lock);
> put_task_struct(task);
> return err;
> }
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index f022f581ac29..861f22bd4706 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -55,6 +55,7 @@ struct oom_control {
> };
>
> extern struct mutex oom_lock;
> +extern struct mutex oom_adj_lock;
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On 2020-08-25 12:50, Stephen Boyd wrote: Quoting Bjorn Andersson (2020-08-24 09:42:12) On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote: > Quoting Sibi Sankar (2020-08-21 13:49:20) > > Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the > > status of the PM domain unaltered during suspend/resume respectively. > > The flags are aimed at power domains coupled to co-processors which > > enter low-power modes independent to that of the application processor. > > > > Specifically the flags are to be used by the power domains exposed > > by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These > > power domains are used to notify the Always on Subsystem (AOSS) that > > a particular co-processor is up. AOSS uses this information to wait > > for the co-processors to suspend before starting its sleep sequence. > > The application processor powers off these power domains only if the > > co-processor has crashed or powered off and remains unaltered during > > system suspend/resume. > > Why are these power domains instead of some QMP message sent during > remote proc power up? The understanding I gained as I researched this, was that with this property enabled resources related to the particular subsystem will be kept enabled when the apss enters some power save mode. So my interpretation was that it does "keep something powered". It looks like it tells AOSS that the processor is booted and to start considering these processors in the SoC wide system suspend sequence. Otherwise I guess the RPMh buckets associated with these remoteprocs don't count in the aggregation and sleep/wake sequences that AOSS runs through when putting the SoC into low power mode. I'm not sure it actually "keeps something powered" so much as it lets something be powered off. Sibi? That is just a part of equation i.e AOSS doesn't enter sleep until the remote processors enter RPMh assisted sleep. This also implies that if the respective remote processor has to come out of low power states it will need to wait for AOSS to come out of sleep. So clearly remote processors are dependent on certain resources to be enabled by the AOSS but the resources may not be restricted to just corners. Another question, why can't the processors tell AOSS themselves about their boot state? I guess because they may crash or be powered down and then AOSS wouldn't know? Fair enough I guess, but I don't think this is mentioned anywhere. > If this has been discussed before feel free to > disregard and please link to prior mailing list discussions. > There where some discussions related to the "QDSS clk" in that series, but I don't remember getting any feedback on modelling these things as power-domains. > I find it odd that this is modeled as a power domain instead of some > Qualcomm specific message that the remoteproc driver sends to AOSS. Is > there some sort of benefit the driver gets from using the power domain > APIs for this vs. using a custom API? We need to send "up" and "down" notifications and this needs to happen at the same time as other standard resources are enabled/disabled. Further more, at the time the all resources handled by the downstream driver was either power-domains (per above understanding) or clocks, so it made sense to me not to spin up a custom API. So the benefit is not spinning up a custom API? I'm not Ulf, but it looks like this is hard to rationalize about as a power domain. It doesn't have any benefit to model it this way besides to make it possible to turn on with other power domains. This modem remoteproc drivers isn't SoC agnostic anyway, it relies on SMEM APIs, so standing up another small qmp_remoteproc_booted() and qmp_remoteproc_shutdown() API would avoid adding a genpd flag here that probably will never be used outside of this corner-case. There is also some get/put EPROBE_DEFER sort of logic to implement, but otherwise it would be possible to do this outside of power domains, and that seems better given that this isn't really a power domain to start with. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [net v3 PATCH] net: ethernet: ti: cpsw_new: fix error handling in cpsw_ndo_vlan_rx_kill_vid()
From: Murali Karicheri Date: Mon, 24 Aug 2020 13:01:00 -0400 > + ret = cpsw_ale_del_vlan(cpsw->ale, vid, 0); > + if (ret) > + dev_err(priv->dev, "%s: failed %d: ret %d\n", > + __func__, __LINE__, ret); > + ret = cpsw_ale_del_ucast(cpsw->ale, priv->mac_addr, > + HOST_PORT_NUM, ALE_VLAN, vid); > + if (ret) > + dev_err(priv->dev, "%s: failed %d: ret %d\n", > + __func__, __LINE__, ret); > + ret = cpsw_ale_del_mcast(cpsw->ale, priv->ndev->broadcast, > + 0, ALE_VLAN, vid); > + if (ret) > + dev_err(priv->dev, "%s: failed %d: ret %d\n", > + __func__, __LINE__, ret); > cpsw_ale_flush_multicast(cpsw->ale, ALE_PORT_HOST, vid); These error messages are extremely unhelpful. You're calling three different functions, yet emitting basically the same __func__ for each of those cases. No user can send you a useful bug report immediately if they just have func and line. Please get rid of the "__func__" and "__line__" stuff completely, it's never advisable to ever use that in my opinion. Instead, describe which delete operation failed, optionally with the error return.
Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on a 64 bit system
On Tue, Aug 25, 2020 at 9:12 AM Andy Lutomirski wrote: > I don’t like this at all. Your behavior really shouldn’t depend on > whether the new instructions are available. Also, some day I would > like to change Linux to have the new behavior even if FSGSBASE > instructions are not available, and this will break rr again. (The > current !FSGSBASE behavior is an ugly optimization of dubious value. > I would not go so far as to describe it as correct.) Ok. > I would suggest you do one of the following things: > > 1. Use int $0x80 directly to load 32-bit regs into a child. This > might dramatically simplify your code and should just do the right > thing. I don't know what that means. > 2. Something like your patch but make it unconditional. > > 3. Ask for, and receive, real kernel support for setting FS and GS in > the way that 32-bit code expects. I think the easiest way forward for us would be a PTRACE_GET/SETREGSET like operation that operates on the regsets according to the *tracee*'s bitness (rather than the tracer, as it works currently). Does that sound workable? - Kyle
Re: [PATCH 00/13] lib/generic-radix-tree: genradix bug fix and optimisations.
On Tue, Aug 25, 2020 at 04:00:35PM +, David Laight wrote: > From: 'Marcelo Ricardo Leitner' > > Sent: 25 August 2020 16:41 > > > > On Tue, Aug 25, 2020 at 02:52:34PM +, David Laight wrote: > > > The genradix code is used by SCTP for accessing per-stream data. > > > This means there are quite a lot of lookups but the code wasn't > > > really optimised at all. > > > > My test box is down for the moment and will bring it on later today or > > tomorrow, so I can't test it yet. What should we expect as performance > > gains here? > > Not sure, probably not much, but it ought to show up :-) > There'll be bigger gains on a cpu that has software ilog2(). > > I've only checked SCTP still works. > I've requested 32k streams on a listener - to force a level-2 tree. > I've also done at least one check with a massive pad in the sctp > stream structure. Have you benchmarked at all? Or were you looking at the generated assembly?
Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline
Jani Nikula [25.08.2020 11:55]: > On Fri, 21 Aug 2020, Pavel Machek wrote: >> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote: >>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote: >>> > >>> > Yes, it seems they make things work. (Chris asked for new patch to be >>> > tested, so I am switching to his kernel, but it survived longer than >>> > it usually does.) >>> >>> Ok, so at worst we know how to solve it, at best the reverts won't be >>> needed because Chris' patch will fix the issue properly. >>> >>> So I'll archive this thread, but remind me if this hasn't gotten >>> sorted out in the later rc's. >> >> Yes, thank you, it seems we have a solution w/o the revert. > > For posterity, I'm told the fix is [1]. > > BR, > Jani. > > > [1] https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/ Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard freeezes. I can still ssh into the machine The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes the bug for me. -- Hilsen Harald
Re: [PATCH] MAINTAINERS: add namespace entry
A) If we are going to have this discussion in public we really should include the containers list. B) The challenge is that most of the namespace work has become part of it's upstream subsystem so we really need to list the containers list and ourselves as reviewers, more than maintainers who run a tree for the code. C) You have overstated what I have agreed to here. I have have previously said that I agree that having a MAINTAINERS entry so people who are unfamiliar with the situation with namespaces can find us. Given that most of the changes going forward are likely to be maintenance changes. I also said we need to talk about how we plan to maintain the code here. It feels like you are pushing this hard, and I am not certain why you are pushing and rushing this. With my maintainer hat on my big concern is we catch the issues that will introduce security issue. Recently I have seen a report that there is an issue on Ubuntu kernels where anyone can read /etc/shadow. The problem is that Ubuntu has not been cautions and has not taken the time to figure out how to enable things for unprivileged users safely, and have just enabled the code to be used by unprivileged users because it is useful. In combination with you pushing hard and not taking the time to complete this conversation in private with me, this MAINTAINERS entry makes me uneasy as it feels like you may be looking for a way to push the code into the mainline kernel like has been pushed into the Ubuntu kernel. I may be completely wrong I just don't know what to make of your not finishing our conversation in private, and forcing my hand by posting this patch publicly. The files you have listed are reasonable for a maintainers entry as they have no other maintainers. I know I have been less active after the birth of my young son, and I know the practical rule is that the person who does the work is the maintainer. At the same time I am not convinced you are actually going to do the work to make new code maintainable and not a problem for other kernel developers. A big part the job over the years has been to make the namespace ideas proposed sane, and to keep the burden from other maintainers of naive and terrible code. Pushing this change before we finished our private conversation makes me very nervous on that front. Eric Christian Brauner writes: > Namespace maintainership has never been formalized which has led to confusion > when people need to determine where to send patches and who should take a look > at them. Especially, since we have a dedicated list > containers.lists.linuxfoundation.org already for a long time. In preparation > of > this patch I added the containers.lists.linuxfoundation.org mailing list to be > archived on lore. > > This will not just make it easier to catch and review patches specific to > namespaces and containers but also for changes not specifically touching > namespaces but which nevertheless will have impact on namespaces and > containers. > > Add an entry for Eric (who agreed to this) and me and add a first batch of > files that are relevant. Currently, only a small set of files are added and > only such namespaces that haven't gotten a separate maintainers entry (e.g. > time namespaces). I expect this to grow more entries and/or regular > expressions > over time. For now these entries here are sufficient. I intend to route this > patch upstream soon. > > Cc: "Eric W. Biederman" > Signed-off-by: Christian Brauner > --- > MAINTAINERS | 20 > 1 file changed, 20 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f0068bceeb61..272211cdc327 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11892,6 +11892,26 @@ S: Supported > W: https://www.cspi.com/ethernet-products/support/downloads/ > F: drivers/net/ethernet/myricom/myri10ge/ > > +NAMESPACES AND CONTAINERS > +M: Christian Brauner > +M: Eric W. Biederman > +L: containers.lists.linuxfoundation.org > +S: Supported > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > +T: > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > +F: ipc/namespace.c > +F: kernel/nsproxy.c > +F: kernel/pid_namespace.c > +F: kernel/user_namespace.c > +F: kernel/utsname.c > +F: include/linux/nsproxy.h > +F: include/linux/ipc_namespace.h > +F: include/linux/ns_common.h > +F: include/linux/nsproxy.h > +F: include/linux/pid_namespace.h > +F: include/linux/user_namespace.h > +F: include/linux/utsname.h > + > NAND FLASH SUBSYSTEM > M: Miquel Raynal > R: Richard Weinberger > > base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd
[PATCH 2/4] ARM: dts: r8a7742-iwg21d-q7: Add SPI NOR support
Add support for the SPI NOR device which is connected to MSIOF0 interface
on the iWave RainboW-G21d-q7 board.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 31 +
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index 73300ab46ea6..e709a132f2f7 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -220,6 +220,32 @@
status = "okay";
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ cs-gpios = < 13 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ flash1: flash@0 {
+ compatible = "sst,sst25vf016b", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+ m25p,fast-read;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "user";
+ reg = <0x 0x0020>;
+ };
+ };
+ };
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -266,6 +292,11 @@
function = "i2c2";
};
+ msiof0_pins: msiof0 {
+ groups = "msiof0_clk", "msiof0_tx", "msiof0_rx";
+ function = "msiof0";
+ };
+
scifa2_pins: scifa2 {
groups = "scifa2_data_c";
function = "scifa2";
--
2.17.1
[PATCH 3/4] ARM: dts: r8a7742-iwg21d-q7: Add can0 support to carrier board
This patch enables CAN0 interface exposed through connector J20 on the
carrier board.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index e709a132f2f7..070fc9729b39 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -198,6 +198,13 @@
};
};
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -214,6 +221,15 @@
};
};
+ {
+ can-trx-en-gpio{
+ gpio-hog;
+ gpios = <28 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "can-trx-en-gpio";
+ };
+};
+
{
pinctrl-0 = <_pins>;
pinctrl-names = "default";
@@ -287,6 +303,11 @@
function = "tpu0";
};
+ can0_pins: can0 {
+ groups = "can0_data_d";
+ function = "can0";
+ };
+
i2c2_pins: i2c2 {
groups = "i2c2_b";
function = "i2c2";
--
2.17.1
[PATCH 1/4] ARM: dts: r8a7742-iwg21d-q7: Enable PCIe Controller
Enable PCIe Controller and set PCIe bus clock frequency.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index 9bf4fbd9c736..73300ab46ea6 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -238,6 +238,18 @@
/* status = "okay"; */
};
+_bus_clk {
+ clock-frequency = <1>;
+};
+
+ {
+ /* SW2[6] determines which connector is activated
+* ON = PCIe X4 (connector-J7)
+* OFF = mini-PCIe (connector-J26)
+*/
+ status = "okay";
+};
+
{
avb_pins: avb {
groups = "avb_mdio", "avb_gmii";
--
2.17.1
[PATCH 0/4] iWave G21D-Q7 enable PCIe, flash, CAN and SD2 LED
Hi All, This patch series enables PCIe, SPI NOR flash, CAN0 and SD2 LED indication on iWave G21D-Q7 board. Patches apply on top of [1] and also dependent on patch [2] [1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/ renesas-devel.git/log/?h=renesas-arm-dt-for-v5.10 [2] https://patchwork.kernel.org/patch/11712541/ Cheers, Prabhakar Lad Prabhakar (4): ARM: dts: r8a7742-iwg21d-q7: Enable PCIe Controller ARM: dts: r8a7742-iwg21d-q7: Add SPI NOR support ARM: dts: r8a7742-iwg21d-q7: Add can0 support to carrier board ARM: dts: r8a7742-iwg21d-q7: Enable SD2 LED indication arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 74 + 1 file changed, 74 insertions(+) -- 2.17.1
[PATCH 4/4] ARM: dts: r8a7742-iwg21d-q7: Enable SD2 LED indication
Add support for LED trigger on SD2 interface.
Signed-off-by: Lad Prabhakar
Reviewed-by: Chris Paterson
---
arch/arm/boot/dts/r8a7742-iwg21d-q7.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
index 070fc9729b39..6d31d2401481 100644
--- a/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
+++ b/arch/arm/boot/dts/r8a7742-iwg21d-q7.dts
@@ -63,6 +63,16 @@
enable-gpios = < 11 GPIO_ACTIVE_HIGH>;
};
+ leds {
+ compatible = "gpio-leds";
+
+ sdhi2_led {
+ label = "sdio-led";
+ gpios = < 22 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "mmc1";
+ };
+ };
+
lvds-receiver {
compatible = "ti,ds90cf384a", "lvds-decoder";
vcc-supply = <_3v3_tft1>;
--
2.17.1
Re: [PATCH] IB/qib: remove superfluous fallthrough statements
On Tue, 2020-08-25 at 11:19 -0500, Gustavo A. R. Silva wrote:
>
> On 8/25/20 10:51, Alex Dewar wrote:
> > Commit 36a8f01cd24b ("IB/qib: Add congestion control agent implementation")
> > erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
> > were later converted to fallthrough statements by commit df561f6688fe
> > ("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
> > warning about unreachable code.
> >
> > Remove the fallthrough statements and replace the mass of gotos with
> > simple return statements to make the code terser and less bug-prone.
> >
>
> This should be split up into two separate patches: one to address the
> fallthrough markings, and another one for the gotos.
I don't think it's necessary to break this into multiple patches.
Logical changes in a single patch are just fine, micro patches
aren't that useful.
Re: [RESEND PATCH v1 2/4] dt-bindings: power: reset: Add alternate reboot mode format
Hi,
On Tue, Aug 18, 2020 at 11:54:14AM -0700, Elliot Berman wrote:
> Current reboot-mode device tree schema does not support reboot commands
> with spaces in them [1]. Add an optional new node "reboot-mode-names"
> and "reboot-mode-magic" which add an array of strings and u32s,
> respectively which would permit any string in this framework.
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/md/dm-verity-target.c?h=v5.5#n255
>
> Signed-off-by: Elliot Berman
> ---
I'm waiting for an Ack from Rob for this one.
-- Sebastian
> .../devicetree/bindings/power/reset/reboot-mode.yaml| 17
> +
> 1 file changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> index a6c9102..4ea6b33 100644
> --- a/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> @@ -19,6 +19,9 @@ description: |
>the bootloader what to do when the system reboots, and should be named
>as mode-xxx = (xxx is mode name, magic should be a non-zero value).
>
> + reboot-mode-magic and reboot-mode-names may be used in addition/instead of
> + mode-xxx style.
> +
>For example, modes common Android platform are:
> - normal: Normal reboot mode, system reboot with command "reboot".
> - recovery: Android Recovery mode, it is a mode to format the device or
> update a new image.
> @@ -32,6 +35,14 @@ properties:
>description: |
> Default value to set on a reboot if no command was provided.
>
> + reboot-mode-names:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: List of reboot commands, paired with reboot-mode-magic by
> index
> +
> + reboot-mode-magic:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: List of reboot magic, paired with reboot-mode-names by index
> +
> patternProperties:
>"^mode-.*$":
> $ref: /schemas/types.yaml#/definitions/uint32
> @@ -44,4 +55,10 @@ examples:
>mode-bootloader = <2>;
>mode-loader = <3>;
> };
> +
> + - |
> +reboot-mode {
> + reboot-mode-names = "normal", "bootloader", "dm-verity device
> corrupted";
> + reboot-mode-magic = <0x0>, <0x1>, <0xf>;
> +};
> ...
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
signature.asc
Description: PGP signature
Re: [PATCH 6/7] mm: Pass pvec directly to find_get_entries
On Tue, Aug 25, 2020 at 02:28:14PM +0100, Matthew Wilcox wrote: > On Tue, Aug 25, 2020 at 02:33:24PM +0200, Jan Kara wrote: > > On Mon 24-08-20 18:36:39, Matthew Wilcox wrote: > > > We already have functions in filemap which take a pagevec, eg > > > page_cache_delete_batch() and delete_from_page_cache_batch(). > > > > Right but those are really pretty internal helper functions so I don't > > think they form or strong precedence. > > To be honest, I saw that as being the way forward for the page cache APIs. > If we're going to use a batching mechanism, it should be pagevecs, and > it should be built into the page cache interfaces rather than hanging > out off on the side. Agreed. > > > So if we're going to merge the two functions, it seems more natural to > > > have it in filemap.c and called find_get_entries(), but I'm definitely > > > open to persuasion on this! > > > > I agree that having non-trivial xarray code in mm/swap.c isn't attractive > > either. Dunno, I dislike the inconsistency between find_get_pages() and > > find_get_entries() you create but they aren't completely consistent anyway > > so I can live with that. Or we can just leave the pagevec_lookup_entries() > > wrapper and the API will stay consistent... > > I was thinking about this some more [1] [2]. I think we can get to the > point where find_get_pages(), find_get_entries() and find_get_pages_tag() > (and all their variants) end up taking a pagevec as their last argument. Agreed. > Also, I was thinking that all these names are wrong. Really, they're > mapping_get_pages(), mapping_get_entries() and mapping_get_marked_pages(). > So maybe I should move in that direction. That sounds like a lateral move in naming to me. The mapping prefix is a slight improvement, but without the "find" it sounds like a refcount operation and hides the fact that this is doing some sort of lookup and has higher complexity. It also makes working on this code easier on people not yet familiar with it at the cost of people familiar with it. Remembering new names for known concepts is a ton of mental churn. So IMO the new names should be unambigously and significantly better than the old ones to justify this. Signed: somebody who is still struggling with the change from exceptional entries in the radix tree to value entries in the xarray (Are pointers or integers the values? Aren't they both "values"?)
Re: [net-next v5 2/2] seg6: Add documentation for seg6_inherit_inner_ipv4_dscp sysctl
From: Ahmed Abdelsalam Date: Tue, 25 Aug 2020 18:01:01 +0200 > patch fixed and resent. You must resubmit the entire patch series when you update any patch in the series. You should also provide a proper header "[PATCH 0/N]" posting for your series which explains what the series does, how does it do it, and why does it do it that way. Thank you.
Re: [PATCH v2] fs/ceph: use pipe_get_pages_alloc() for pipe
On Mon, 2020-08-24 at 18:20 -0700, John Hubbard wrote:
> This reduces, by one, the number of callers of iov_iter_get_pages().
> That's helpful because these calls are being audited and converted over
> to use iov_iter_pin_user_pages(), where applicable. And this one here is
> already known by the caller to be only for ITER_PIPE, so let's just
> simplify it now.
>
> Signed-off-by: John Hubbard
> ---
>
> OK, here's a v2 that does EXPORT_SYMBOL_GPL, instead of EXPORT_SYMBOL,
> that's the only change from v1. That should help give this patch a
> clear bill of passage. :)
>
> thanks,
> John Hubbard
> NVIDIA
>
> fs/ceph/file.c | 3 +--
> include/linux/uio.h | 3 ++-
> lib/iov_iter.c | 6 +++---
> 3 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index d51c3f2fdca0..d3d7dd957390 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -879,8 +879,7 @@ static ssize_t ceph_sync_read(struct kiocb *iocb, struct
> iov_iter *to,
> more = len < iov_iter_count(to);
>
> if (unlikely(iov_iter_is_pipe(to))) {
> - ret = iov_iter_get_pages_alloc(to, , len,
> -_off);
> + ret = pipe_get_pages_alloc(to, , len, _off);
> if (ret <= 0) {
> ceph_osdc_put_request(req);
> ret = -ENOMEM;
> diff --git a/include/linux/uio.h b/include/linux/uio.h
> index 3835a8a8e9ea..270a4dcf5453 100644
> --- a/include/linux/uio.h
> +++ b/include/linux/uio.h
> @@ -226,7 +226,8 @@ ssize_t iov_iter_get_pages(struct iov_iter *i, struct
> page **pages,
> ssize_t iov_iter_get_pages_alloc(struct iov_iter *i, struct page ***pages,
> size_t maxsize, size_t *start);
> int iov_iter_npages(const struct iov_iter *i, int maxpages);
> -
> +ssize_t pipe_get_pages_alloc(struct iov_iter *i, struct page ***pages,
> + size_t maxsize, size_t *start);
> const void *dup_iter(struct iov_iter *new, struct iov_iter *old, gfp_t
> flags);
>
> static inline size_t iov_iter_count(const struct iov_iter *i)
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index 5e40786c8f12..6290998df480 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1355,9 +1355,8 @@ static struct page **get_pages_array(size_t n)
> return kvmalloc_array(n, sizeof(struct page *), GFP_KERNEL);
> }
>
> -static ssize_t pipe_get_pages_alloc(struct iov_iter *i,
> -struct page ***pages, size_t maxsize,
> -size_t *start)
> +ssize_t pipe_get_pages_alloc(struct iov_iter *i, struct page ***pages,
> + size_t maxsize, size_t *start)
> {
> struct page **p;
> unsigned int iter_head, npages;
> @@ -1387,6 +1386,7 @@ static ssize_t pipe_get_pages_alloc(struct iov_iter *i,
> kvfree(p);
> return n;
> }
> +EXPORT_SYMBOL_GPL(pipe_get_pages_alloc);
>
> ssize_t iov_iter_get_pages_alloc(struct iov_iter *i,
> struct page ***pages, size_t maxsize,
Thanks. I've got a v1 of this in the ceph-client/testing branch and it
seems fine so far.
I'd prefer an ack from Al on one or the other though, since I'm not sure
he wants to expose this primitive, and in the past he hasn't been
enamored with EXPORT_SYMBOL_GPL, because its meaning wasn't well
defined. Maybe that's changed since.
As a side note, Al also asked privately why ceph special cases
ITER_PIPE. I wasn't sure either, so I did a bit of git-archaeology. The
change was added here:
---8<---
commit
7ce469a53e7106acdaca2e25027941d0f7c12a8e
Author: Yan, Zheng
Date: Tue Nov 8 21:54:34 2016 +0800
ceph: fix splice read for no Fc capability case
When iov_iter type is ITER_PIPE, copy_page_to_iter() increases
the page's reference and add the page to a pipe_buffer. It also
set the pipe_buffer's ops to page_cache_pipe_buf_ops. The comfirm
callback in page_cache_pipe_buf_ops expects the page is from page
cache and uptodate, otherwise it return error.
For ceph_sync_read() case, pages are not from page cache. So we
can't call copy_page_to_iter() when iov_iter type is ITER_PIPE.
The fix is using iov_iter_get_pages_alloc() to allocate pages
for the pipe. (the code is similar to default_file_splice_read)
Signed-off-by: Yan, Zheng
---8<---
If we don't have Fc (FILE_CACHE) caps then the client's not allowed to
cache data and so we can't use the pagecache. I'm not certain special
casing pipes in ceph, is the best approach to handle that, but the
confirm callback still seems to work the same way today.
Cheers,
--
Jeff Layton
Re: [RESEND PATCH v1 1/4] dt-bindings: power: reset: Convert reboot-mode to YAML
Hi,
Thanks, queued.
-- Sebastian
On Tue, Aug 18, 2020 at 11:54:13AM -0700, Elliot Berman wrote:
> Convert reboot-mode bindings to YAML.
>
> Signed-off-by: Elliot Berman
> ---
> .../bindings/power/reset/reboot-mode.txt | 25
> .../bindings/power/reset/reboot-mode.yaml | 47
> ++
> 2 files changed, 47 insertions(+), 25 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> create mode 100644
> Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
>
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> deleted file mode 100644
> index de34f27..000
> --- a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -Generic reboot mode core map driver
> -
> -This driver get reboot mode arguments and call the write
> -interface to store the magic value in special register
> -or ram. Then the bootloader can read it and take different
> -action according to the argument stored.
> -
> -All mode properties are vendor specific, it is a indication to tell
> -the bootloader what to do when the system reboots, and should be named
> -as mode-xxx = (xxx is mode name, magic should be a none-zero value).
> -
> -For example modes common on Android platform:
> -- mode-normal: Normal reboot mode, system reboot with command "reboot".
> -- mode-recovery: Android Recovery mode, it is a mode to format the device or
> update a new image.
> -- mode-bootloader: Android fastboot mode, it's a mode to re-flash partitions
> on the Android based device.
> -- mode-loader: A bootloader mode, it's a mode used to download image on
> Rockchip platform,
> -usually used in development.
> -
> -Example:
> - reboot-mode {
> - mode-normal = ;
> - mode-recovery = ;
> - mode-bootloader = ;
> - mode-loader = ;
> - }
> diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> new file mode 100644
> index 000..a6c9102
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/reset/reboot-mode.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic reboot mode core map
> +
> +maintainers:
> + - Andy Yan
> +
> +description: |
> + This driver get reboot mode arguments and call the write
> + interface to store the magic value in special register
> + or ram. Then the bootloader can read it and take different
> + action according to the argument stored.
> +
> + All mode properties are vendor specific, it is a indication to tell
> + the bootloader what to do when the system reboots, and should be named
> + as mode-xxx = (xxx is mode name, magic should be a non-zero value).
> +
> + For example, modes common Android platform are:
> +- normal: Normal reboot mode, system reboot with command "reboot".
> +- recovery: Android Recovery mode, it is a mode to format the device or
> update a new image.
> +- bootloader: Android fastboot mode, it's a mode to re-flash partitions
> on the Android based device.
> +- loader: A bootloader mode, it's a mode used to download image on
> Rockchip platform,
> + usually used in development.
> +
> +properties:
> + mode-normal:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: |
> +Default value to set on a reboot if no command was provided.
> +
> +patternProperties:
> + "^mode-.*$":
> +$ref: /schemas/types.yaml#/definitions/uint32
> +
> +examples:
> + - |
> +reboot-mode {
> + mode-normal = <0>;
> + mode-recovery = <1>;
> + mode-bootloader = <2>;
> + mode-loader = <3>;
> +};
> +...
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
signature.asc
Description: PGP signature
Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert bindings to json-schema
On Tue, Aug 25, 2020 at 2:47 AM Sagar Kadam wrote: > > Hello Rob, > > > -Original Message- > > From: Rob Herring > > Sent: Monday, August 24, 2020 11:06 PM > > To: Sagar Kadam > > Cc: a...@eecs.berkeley.edu; devicet...@vger.kernel.org; Paul Walmsley ( > > Sifive) ; robh...@kernel.org; Yash Shah > > ; pal...@dabbelt.com; linux- > > ker...@vger.kernel.org; linux-ri...@lists.infradead.org > > Subject: Re: [PATCH 1/1] dt-bindings: riscv: sifive-l2-cache: convert > > bindings > > to json-schema > > > > [External Email] Do not click links or attachments unless you recognize the > > sender and know the content is safe > > > > On Mon, 24 Aug 2020 13:20:21 +0530, Sagar Kadam wrote: > > > Convert the device tree bindings for the SiFive's FU540-C000 SoC's L2 > > > Cache controller to YAML format. > > > > > > Signed-off-by: Sagar Kadam > > > --- > > > .../devicetree/bindings/riscv/sifive-l2-cache.txt | 51 > > > .../devicetree/bindings/riscv/sifive-l2-cache.yaml | 93 > > > ++ > > > 2 files changed, 93 insertions(+), 51 deletions(-) delete mode > > > 100644 Documentation/devicetree/bindings/riscv/sifive-l2-cache.txt > > > create mode 100644 > > > Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml > > > > > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > > > I had checked using DT_SCHEMA_FILES option due to which it didn't catch any > error on other > schemas. Without this I could regenerate the error you mentioned. > I will fix it and update. Sorry for the error. Update your kernel. DT_SCHEMA_FILES setting no longer matters on current tree. It only affects 'dtbs_check' now. Rob
Re: [PATCH 0/3] SiFive DDR controller and EDAC support
On Tue, 25 Aug 2020 09:19:58 PDT (-0700), b...@alien8.de wrote: On Tue, Aug 25, 2020 at 09:02:54AM -0700, Palmer Dabbelt wrote: Thanks. These look good to me and I'm happy to take them through the RISC-V tree, but I'm going to wait for a bit to see if there are any comments from the maintainers of the various subsystems before doing so. I'll have a look at the EDAC bits these days and give you an ACK if they're ok. Thanks!
Re: [PATCH 0/3] SiFive DDR controller and EDAC support
On Tue, Aug 25, 2020 at 09:02:54AM -0700, Palmer Dabbelt wrote: > Thanks. These look good to me and I'm happy to take them through the RISC-V > tree, but I'm going to wait for a bit to see if there are any comments from > the > maintainers of the various subsystems before doing so. I'll have a look at the EDAC bits these days and give you an ACK if they're ok. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH] USB: core: limit access to rawdescriptors which were not allocated
From: Yanfei Xu
When using systemcall to read the rawdescriptors, make sure we won't
access to the rawdescriptors never allocated, which are number
exceed the USB_MAXCONFIG.
Reported-by: syzbot+256e56ddde8b8957e...@syzkaller.appspotmail.com
Signed-off-by: Yanfei Xu
---
drivers/usb/core/sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index a2ca38e25e0c..1a7a625e5f55 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -895,7 +895,8 @@ read_descriptors(struct file *filp, struct kobject *kobj,
* configurations (config plus subsidiary descriptors).
*/
for (cfgno = -1; cfgno < udev->descriptor.bNumConfigurations &&
- nleft > 0; ++cfgno) {
+ nleft > 0 &&
+ cfgno < USB_MAXCONFIG; ++cfgno) {
if (cfgno < 0) {
src = >descriptor;
srclen = sizeof(struct usb_device_descriptor);
--
2.18.2
Re: [PATCH v4 00/10] Function Granular KASLR
On 8/21/20 7:02 PM, Kristen Carlson Accardi wrote:
On Wed, 2020-07-22 at 16:33 -0500, Josh Poimboeuf wrote:
On Wed, Jul 22, 2020 at 12:56:10PM -0700, Kristen Carlson Accardi
wrote:
On Wed, 2020-07-22 at 12:42 -0700, Kees Cook wrote:
On Wed, Jul 22, 2020 at 11:07:30AM -0500, Josh Poimboeuf wrote:
On Wed, Jul 22, 2020 at 07:39:55AM -0700, Kees Cook wrote:
On Wed, Jul 22, 2020 at 11:27:30AM +0200, Miroslav Benes
wrote:
Let me CC live-patching ML, because from a quick glance
this is
something
which could impact live patching code. At least it
invalidates
assumptions
which "sympos" is based on.
In a quick skim, it looks like the symbol resolution is using
kallsyms_on_each_symbol(), so I think this is safe? What's a
good
selftest for live-patching?
The problem is duplicate symbols. If there are two static
functions
named 'foo' then livepatch needs a way to distinguish them.
Our current approach to that problem is "sympos". We rely on
the
fact
that the second foo() always comes after the first one in the
symbol
list and kallsyms. So they're referred to as foo,1 and foo,2.
Ah. Fun. In that case, perhaps the LTO series has some solutions.
I
think builds with LTO end up renaming duplicate symbols like
that, so
it'll be back to being unique.
Well, glad to hear there might be some precendence for how to solve
this, as I wasn't able to think of something reasonable off the top
of
my head. Are you speaking of the Clang LTO series?
https://lore.kernel.org/lkml/20200624203200.78870-1-samitolva...@google.com/
I'm not sure how LTO does it, but a few more (half-brained) ideas
that
could work:
1) Add a field in kallsyms to keep track of a symbol's original
offset
before randomization/re-sorting. Livepatch could use that field
to
determine the original sympos.
2) In fgkaslr code, go through all the sections and mark the ones
which
have duplicates (i.e. same name). Then when shuffling the
sections,
skip a shuffle if it involves a duplicate section. That way all
the
duplicates would retain their original sympos.
3) Livepatch could uniquely identify symbols by some feature other
than
sympos. For example:
Symbol/function size - obviously this would only work if
duplicately
named symbols have different sizes.
Checksum - as part of a separate feature we're also looking at
giving
each function its own checksum, calculated based on its
instruction
opcodes. Though calculating checksums at runtime could be
complicated by IP-relative addressing.
I'm thinking #1 or #2 wouldn't be too bad. #3 might be harder.
Hi there! I was trying to find a super easy way to address this, so I
thought the best thing would be if there were a compiler or linker
switch to just eliminate any duplicate symbols at compile time for
vmlinux. I filed this question on the binutils bugzilla looking to see
if there were existing flags that might do this, but H.J. Lu went ahead
and created a new one "-z unique", that seems to do what we would need
it to do.
https://sourceware.org/bugzilla/show_bug.cgi?id=26391
When I use this option, it renames any duplicate symbols with an
extension - for example duplicatefunc.1 or duplicatefunc.2.
I tried out H.J. Lu's branch and built some of the livepatch selftests
with -z unique-symbol and indeed observe the following pattern:
foo, foo.1, foo.2, etc.
for homonym symbol names.
> You could
either match on the full unique name of the specific binary you are
trying to patch, or you match the base name and use the extension to
determine original position. Do you think this solution would work?
I think it could work for klp-relocations.
As a quick test, I was able to hack the WIP klp-convert branch [1] to
generate klp-relocations with the following hack:
const char *foo(void) __asm__("foo.1");
when building foo's target with -z unique-symbol. (The target contained
two static foo() functions.) The asm rename trick exercised the
klp-convert implicit conversion feature, as the symbol was now uniquely
named and included a non-valid C symbol character. User-defined
klp-convert annotation support will require some refactoring, but
shouldn't be too difficult to support as well.
If
so, I can modify livepatch to refuse to patch on duplicated symbols if
CONFIG_FG_KASLR and when this option is merged into the tool chain I
can add it to KBUILD_LDFLAGS when CONFIG_FG_KASLR and livepatching
should work in all cases.
I don't have a grasp on how complicated the alternatives might be, so
I'll let others comment on best paths forward. I just wanted to note
that -z unique-symbol looks like it could reasonable work well for this
niche case.
[1]
https://github.com/joe-lawrence/linux/tree/klp-convert-v5-expanded-v5.8
(not modified for -z unique-symbol, but noted for reference)
-- Joe
[PATCH v2] MAINTAINERS: add namespace entry
Namespace maintainership has never been formalized which has led to confusion when people need to determine where to send patches and who should take a look at them. Especially, since we have a dedicated list containers.lists.linuxfoundation.org already for a long time. In preparation of this patch I added the containers.lists.linuxfoundation.org mailing list to be archived on lore. This will not just make it easier to catch and review patches specific to namespaces and containers but also for changes not specifically touching namespaces but which nevertheless will have impact on namespaces and containers. Add an entry for Eric (who agreed to this) and me and add a first batch of files that are relevant. Currently, only a small set of files are added and only such namespaces that haven't gotten a separate maintainers entry (e.g. time namespaces). I expect this to grow more entries and/or regular expressions over time. For now these entries here are sufficient. I intend to route this patch upstream soon. Cc: "Eric W. Biederman" Signed-off-by: Christian Brauner --- /* v2 */ - fix file ordering (passes cleanly through checkpatch.pl now) --- MAINTAINERS | 19 +++ 1 file changed, 19 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f0068bceeb61..ef636d00a725 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11892,6 +11892,25 @@ S: Supported W: https://www.cspi.com/ethernet-products/support/downloads/ F: drivers/net/ethernet/myricom/myri10ge/ +NAMESPACES AND CONTAINERS +M: Christian Brauner +M: Eric W. Biederman +L: containers.lists.linuxfoundation.org +S: Supported +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ +F: include/linux/ipc_namespace.h +F: include/linux/ns_common.h +F: include/linux/nsproxy.h +F: include/linux/pid_namespace.h +F: include/linux/user_namespace.h +F: include/linux/utsname.h +F: ipc/namespace.c +F: kernel/nsproxy.c +F: kernel/pid_namespace.c +F: kernel/user_namespace.c +F: kernel/utsname.c + NAND FLASH SUBSYSTEM M: Miquel Raynal R: Richard Weinberger base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd -- 2.28.0
Re: [PATCH] rcu-tasks: Fix compilation warning with !CONFIG_TASKS_RCU and CONFIG_TINY_RCU
On Tue, Aug 25, 2020 at 06:22:49PM +0300, Laurent Pinchart wrote:
> Hi Paul,
>
> On Tue, Aug 25, 2020 at 08:02:22AM -0700, Paul E. McKenney wrote:
> > On Sun, Aug 23, 2020 at 06:04:05AM +0300, Laurent Pinchart wrote:
> > > Commit 8344496e8b49 ("rcu-tasks: Conditionally compile
> > > show_rcu_tasks_gp_kthreads()") introduced conditional compilation of
> > > several functions, but forgot one occurrence of
> > > show_rcu_tasks_classic_gp_kthread() that causes the compiler to warn of
> > > an unused static function. Fix it.
> > >
> > > Fixes: 8344496e8b49 ("rcu-tasks: Conditionally compile
> > > show_rcu_tasks_gp_kthreads()")
> > > Signed-off-by: Laurent Pinchart
> > > ---
> > > kernel/rcu/tasks.h | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> > > index 835e2df8590a..bddf3968c1eb 100644
> > > --- a/kernel/rcu/tasks.h
> > > +++ b/kernel/rcu/tasks.h
> > > @@ -590,7 +590,9 @@ void exit_tasks_rcu_finish(void)
> > > __releases(_rcu_exit_srcu)
> > > }
> > >
> > > #else /* #ifdef CONFIG_TASKS_RCU */
> > > +#ifndef CONFIG_TINY_RCU
> > > static void show_rcu_tasks_classic_gp_kthread(void) { }
> > > +#endif /* #ifndef CONFIG_TINY_RCU */
> > > void exit_tasks_rcu_start(void) { }
> > > void exit_tasks_rcu_finish(void) { exit_tasks_rcu_finish_trace(current);
> > > }
> > > #endif /* #else #ifdef CONFIG_TASKS_RCU */
> >
> > Good catch!!!
> >
> > But does the following addition of "static inline" work for you?
>
> They do. I initially added a static inline, and realized #ifdef was used
> extensively when trying to find the proper Fixes: tag, so I went for
> that. I don't mind either way, as long as this gets fixed :-)
This is admittedly an odd .h file, given that it is included but once.
I have applied the following patch with your Reported-by, cc-ing -stable
for v5.8 and later.
Thanx, Paul
> >
> >
> > diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> > index 835e2df..3dc3ffc 100644
> > --- a/kernel/rcu/tasks.h
> > +++ b/kernel/rcu/tasks.h
> > @@ -590,9 +590,9 @@ void exit_tasks_rcu_finish(void)
> > __releases(_rcu_exit_srcu)
> > }
> >
> > #else /* #ifdef CONFIG_TASKS_RCU */
> > -static void show_rcu_tasks_classic_gp_kthread(void) { }
> > -void exit_tasks_rcu_start(void) { }
> > -void exit_tasks_rcu_finish(void) { exit_tasks_rcu_finish_trace(current); }
> > +static inline void show_rcu_tasks_classic_gp_kthread(void) { }
> > +static inline void exit_tasks_rcu_start(void) { }
> > +static inline void exit_tasks_rcu_finish(void) {
> > exit_tasks_rcu_finish_trace(current); }
> > #endif /* #else #ifdef CONFIG_TASKS_RCU */
> >
> > #ifdef CONFIG_TASKS_RUDE_RCU
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH 3/3] PM / Domains: Add support for PM domain on/off notifiers for genpd
On Wed, Aug 19 2020 at 04:41 -0600, Ulf Hansson wrote:
A device may have specific HW constraints that must be obeyed to, before
its corresponding PM domain (genpd) can be powered off - and vice verse at
power on. These constraints can't be managed through the regular runtime PM
based deployment for a device, because the access pattern for it, isn't
always request based. In other words, using the runtime PM callbacks to
deal with the constraints doesn't work for these cases.
For these reasons, let's instead add a PM domain power on/off notification
mechanism to genpd. To add/remove a notifier for a device, the device must
already have been attached to the genpd, which also means that it needs to
be a part of the PM domain topology.
To add/remove a notifier, let's introduce two genpd specific functions:
- dev_pm_genpd_add|remove_notifier()
Note that, to further clarify when genpd power on/off notifiers may be
used, one can compare with the existing CPU_CLUSTER_PM_ENTER|EXIT
notifiers. In the long run, the genpd power on/off notifiers should be able
to replace them, but that requires additional genpd based platform support
for the current users.
Signed-off-by: Ulf Hansson
---
drivers/base/power/domain.c | 130 ++--
include/linux/pm_domain.h | 15 +
2 files changed, 141 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 4b787e1ff188..9cb85a5e8342 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -545,13 +545,21 @@ static int genpd_power_off(struct generic_pm_domain
*genpd, bool one_dev_on,
if (!genpd->gov)
genpd->state_idx = 0;
+ /* Notify consumers that we are about to power off. */
+ ret = raw_notifier_call_chain(>power_notifiers, GENPD_STATE_OFF,
+ NULL);
+ if (ret)
+ return ret;
+
/* Don't power off, if a child domain is waiting to power on. */
- if (atomic_read(>sd_count) > 0)
- return -EBUSY;
+ if (atomic_read(>sd_count) > 0) {
+ ret = -EBUSY;
+ goto busy;
+ }
ret = _genpd_power_off(genpd, true);
if (ret)
- return ret;
+ goto busy;
genpd->status = GENPD_STATE_OFF;
genpd_update_accounting(genpd);
@@ -564,6 +572,9 @@ static int genpd_power_off(struct generic_pm_domain *genpd,
bool one_dev_on,
}
return 0;
+busy:
+ raw_notifier_call_chain(>power_notifiers, GENPD_STATE_ON, NULL);
It would be helpful to abstract these notification related calls into
functions of their own. So, for CPU PM domains, it would help to add
RCU_NONIDLE() around the notifiers, allowing the callbacks to add trace
functions.
--Lina
+ return ret;
}
/**
@@ -606,6 +617,9 @@ static int genpd_power_on(struct generic_pm_domain *genpd,
unsigned int depth)
if (ret)
goto err;
+ /* Inform consumers that we have powered on. */
+ raw_notifier_call_chain(>power_notifiers, GENPD_STATE_ON, NULL);
+
genpd->status = GENPD_STATE_ON;
genpd_update_accounting(genpd);
@@ -948,9 +962,18 @@ static void genpd_sync_power_off(struct generic_pm_domain
*genpd, bool use_lock,
/* Choose the deepest state when suspending */
genpd->state_idx = genpd->state_count - 1;
- if (_genpd_power_off(genpd, false))
+
+ /* Notify consumers that we are about to power off. */
+ if (raw_notifier_call_chain(>power_notifiers,
+ GENPD_STATE_OFF, NULL))
return;
+ if (_genpd_power_off(genpd, false)) {
+ raw_notifier_call_chain(>power_notifiers,
+ GENPD_STATE_ON, NULL);
+ return;
+ }
+
genpd->status = GENPD_STATE_OFF;
list_for_each_entry(link, >child_links, child_node) {
@@ -998,6 +1021,9 @@ static void genpd_sync_power_on(struct generic_pm_domain
*genpd, bool use_lock,
_genpd_power_on(genpd, false);
+ /* Inform consumers that we have powered on. */
+ raw_notifier_call_chain(>power_notifiers, GENPD_STATE_ON, NULL);
+
genpd->status = GENPD_STATE_ON;
}
@@ -1593,6 +1619,101 @@ int pm_genpd_remove_device(struct device *dev)
}
EXPORT_SYMBOL_GPL(pm_genpd_remove_device);
+/**
+ * dev_pm_genpd_add_notifier - Add a genpd power on/off notifier for @dev
+ *
+ * @dev: Device that should be associated with the notifier
+ * @nb: The notifier block to register
+ *
+ * Users may call this function to add a genpd power on/off notifier for an
+ * attached @dev. Only one notifier per device is allowed. The notifier is
+ * sent when genpd is powering on/off the PM domain.
+ *
+ * It is assumed that the user guarantee that the genpd wouldn't be detached
+ * while this routine is getting called.
+ *
+ * Returns 0 on success and negative error values on failures.
+
Re: [PATCH] IB/qib: remove superfluous fallthrough statements
On 8/25/20 10:51, Alex Dewar wrote:
> Commit 36a8f01cd24b ("IB/qib: Add congestion control agent implementation")
> erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
> were later converted to fallthrough statements by commit df561f6688fe
> ("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
> warning about unreachable code.
>
> Remove the fallthrough statements and replace the mass of gotos with
> simple return statements to make the code terser and less bug-prone.
>
This should be split up into two separate patches: one to address the
fallthrough markings, and another one for the gotos.
Thanks
--
Gustavo
Re: [PATCH v5 1/3] drm/vkms: Decouple crc operations from composer
On Mon, Aug 24, 2020 at 11:31 PM Rodrigo Siqueira
wrote:
>
> In the vkms_composer.c, some of the functions related to CRC and compose
> have interdependence between each other. This patch reworks some
> functions inside vkms_composer to make crc and composer computation
> decoupled.
>
> This patch is preparation work for making vkms able to support new
> features.
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 49
> 1 file changed, 29 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4f3b07a32b60..4d8bc04bb6ee 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -108,35 +108,31 @@ static void compose_cursor(struct vkms_composer
> *cursor_composer,
> primary_composer, cursor_composer);
> }
>
> -static uint32_t _vkms_get_crc(struct vkms_composer *primary_composer,
> - struct vkms_composer *cursor_composer)
> +static int compose_planes(void **vaddr_out,
> + struct vkms_composer *primary_composer,
> + struct vkms_composer *cursor_composer)
> {
> struct drm_framebuffer *fb = _composer->fb;
> struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj);
> - void *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> - u32 crc = 0;
>
> - if (!vaddr_out) {
> - DRM_ERROR("Failed to allocate memory for output frame.");
> - return 0;
> + if (!*vaddr_out) {
> + *vaddr_out = kzalloc(vkms_obj->gem.size, GFP_KERNEL);
> + if (!*vaddr_out) {
> + DRM_ERROR("Cannot allocate memory for output frame.");
> + return -ENOMEM;
> + }
> }
>
> - if (WARN_ON(!vkms_obj->vaddr)) {
> - kfree(vaddr_out);
> - return crc;
> - }
> + if (WARN_ON(!vkms_obj->vaddr))
> + return -EINVAL;
>
> - memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> + memcpy(*vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
>
> if (cursor_composer)
> - compose_cursor(cursor_composer, primary_composer, vaddr_out);
> + compose_cursor(cursor_composer, primary_composer, *vaddr_out);
>
> - crc = compute_crc(vaddr_out, primary_composer);
> -
> - kfree(vaddr_out);
> -
> - return crc;
> + return 0;
> }
>
> /**
> @@ -157,9 +153,11 @@ void vkms_composer_worker(struct work_struct *work)
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> struct vkms_composer *primary_composer = NULL;
> struct vkms_composer *cursor_composer = NULL;
> + void *vaddr_out = NULL;
> u32 crc32 = 0;
> u64 frame_start, frame_end;
> bool crc_pending;
> + int ret;
>
> spin_lock_irq(>composer_lock);
> frame_start = crtc_state->frame_start;
> @@ -183,14 +181,25 @@ void vkms_composer_worker(struct work_struct *work)
> if (crtc_state->num_active_planes == 2)
> cursor_composer = crtc_state->active_planes[1]->composer;
>
> - if (primary_composer)
> - crc32 = _vkms_get_crc(primary_composer, cursor_composer);
> + if (!primary_composer)
> + return;
> +
> + ret = compose_planes(_out, primary_composer, cursor_composer);
> + if (ret) {
> + if (ret == -EINVAL)
> + kfree(vaddr_out);
> + return;
> + }
> +
> + crc32 = compute_crc(vaddr_out, primary_composer);
>
> /*
> * The worker can fall behind the vblank hrtimer, make sure we catch
> up.
> */
> while (frame_start <= frame_end)
> drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> +
> + kfree(vaddr_out);
> }
>
> static const char * const pipe_crc_sources[] = {"auto"};
> --
> 2.28.0
>
Tested-by: Melissa Wen
Re: [PATCH v11 8/9] x86/vdso: Insert endbr32/endbr64 to vDSO
On 8/24/2020 5:33 PM, Andy Lutomirski wrote: On Mon, Aug 24, 2020 at 5:30 PM Yu-cheng Yu wrote: From: "H.J. Lu" When Indirect Branch Tracking (IBT) is enabled, vDSO functions may be called indirectly, and must have ENDBR32 or ENDBR64 as the first instruction. The compiler must support -fcf-protection=branch so that it can be used to compile vDSO. Signed-off-by: H.J. Lu Signed-off-by: Yu-cheng Yu Acked-by: Andy Lutomirski I revoke my Ack. Please don't repeat the list of object files. Maybe add the option to CFL? I will update the patch. Yu-cheng
Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on a 64 bit system
> On Aug 24, 2020, at 5:46 PM, Kyle Huey wrote: > > On Mon, Aug 24, 2020 at 5:31 PM Andy Lutomirski wrote: >> >>> On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin wrote: >>> >>> On 2020-08-24 14:10, Andy Lutomirski wrote: PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor. PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base accordingly. PTRACE_READ_SEGMENT_BASE: pass in a segment selector, get a base out. You would use this to populate the base fields. or perhaps a ptrace SETREGS variant that tries to preserve the old base semantics and magically sets the bases to match the selectors if the selectors are nonzero. Do any of these choices sound preferable to any of you? >>> >>> My suggestion would be to export the GDT and LDT as a (readonly or mostly >>> readonly) regset(s) rather than adding entirely new operations. We could >>> allow >>> the LDT and the per-thread GDT entries to be written, subject to the same >>> limitations as the corresponding system calls. >>> >> >> That seems useful, although we'd want to do some extensive >> sanitization of the GDT. But maybe it's obnoxious to ask Kyle and >> Robert to parse the GDT, LDT, and selector just to emulate the >> demented pre-5.9 ptrace() behavior. >> >> --Andy > > We've already addressed the main issue on rr's side[0]. The only > outstanding issue is that if you record a trace with 32 bit programs > on a pre-5.9 64 bit kernel and then try to replay it on 5.9 it won't > work. If you hit this case rr will print an error message telling you > to boot your 5.9 kernel with nofsgsbase if you want to replay the > trace. I think that's probably sufficient. 32 bit is legacy stuff we > don't care that much about anyways, replaying traces on a different > kernel/machine has always been a bit dicey, and if you absolutely must > do it there is a workaround. I'm not inclined to do much work to > support the narrow remaining case. > > - Kyle > > [0] Namely, we're tracking fs/gsbase for 32 bit tracees on 64 bit > kernels where the fs/gsbase instructions work in new recordings now: > https://github.com/mozilla/rr/commit/c3292c75dbd8c9ce5256496108965c0442424eef I don’t like this at all. Your behavior really shouldn’t depend on whether the new instructions are available. Also, some day I would like to change Linux to have the new behavior even if FSGSBASE instructions are not available, and this will break rr again. (The current !FSGSBASE behavior is an ugly optimization of dubious value. I would not go so far as to describe it as correct.) I would suggest you do one of the following things: 1. Use int $0x80 directly to load 32-bit regs into a child. This might dramatically simplify your code and should just do the right thing. 2. Something like your patch but make it unconditional. 3. Ask for, and receive, real kernel support for setting FS and GS in the way that 32-bit code expects. Also, for other x86 kernel folks playing along, WTF is task_user_regset_vew() about? It has eight callers, in two groups, and as far as I can tell every single call returns _x86_64_view because it's only called in the 64-bit and x32 syscall paths, and those are only reachable using the 64-bit SYSCALL instruction. I suppose the exception is if someone ptraces the ptracer and changes CS at syscall entry. In any case, if task_user_regset_view() ever returns anything else, the code will malfunction. I'll send a patch to get rid of it. --Andy
Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names
Hi, On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan wrote: > > Currently the non-strict or lazy mode of TLB invalidation can only be set > for all or no domains. This works well for development platforms where > setting to non-strict/lazy mode is fine for performance reasons but on > production devices, we need a more fine grained control to allow only > certain peripherals to support this mode where we can be sure that it is > safe. So add support to filter non-strict/lazy mode based on the device > names that are passed via cmdline parameter "iommu.nonstrict_device". > > Example: iommu.nonstrict_device="7c4000.sdhci,a60.dwc3,6048000.etr" I have an inherent dislike of jamming things like this onto the command line. IMHO the command line is the last resort for specifying configuration and generally should be limited to some specialized debug options and cases where the person running the kernel needs to override a config that was set by the person (or company) compiling the kernel. Specifically, having a long/unwieldy command line makes it harder to use for the case when an end user actually wants to use it to override something. It's also just another place to look for config. The other problem is that this doesn't necessarily scale very well. While it works OK for embedded cases it doesn't work terribly well for distributions. I know that in an out-of-band thread you indicated that it doesn't break anything that's not already broken (AKA this doesn't fix the distro case but it doesn't make it worse), it would be better to come up with a more universal solution. Ideally it feels like we should figure out how to tag devices in a generic manner automatically (hardcode at the driver or in the device tree). I think the out-of-band discussions talked about "external facing" and the like. We could also, perhaps, tag devices that have "binary blob" firmware if we wanted. Then we'd have a policy (set by Kconfig, perhaps overridable via commandline) that indicated the strictness level for the various classes of devices. So policy would be decided by KConfig and/or command line. -Doug
Re: [PATCH v5 3/3] drm/vkms: Add support for writeback
On Tue, Aug 25, 2020 at 12:45 PM Melissa Wen wrote:
>
> On 08/24, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change in V4 (Emil and Melissa):
> > - Move signal completion above drm_crtc_add_crc_entry()
> > - Make writeback always available
> > - Use appropriate namespace
> > - Drop fb check in vkms_wb_atomic_commit
> > - Make vkms_set_composer visible for writeback code
> > - Enable composer operation on prepare_job and disable it on cleanup_job
> >
> > Change in V3 (Daniel):
> > - If writeback is enabled, compose everything into the writeback buffer
> > instead of CRC private buffer
> > - Guarantees that the CRC will match exactly what we have in the
> > writeback buffer.
> >
> > Change in V2:
> > - Rework signal completion (Brian)
> > - Integrates writeback with active_planes (Daniel)
> > - Compose cursor (Daniel)
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/Makefile | 9 +-
> > drivers/gpu/drm/vkms/vkms_composer.c | 21 +++-
> > drivers/gpu/drm/vkms/vkms_drv.h | 11 +-
> > drivers/gpu/drm/vkms/vkms_output.c| 4 +
> > drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++
> > 5 files changed, 181 insertions(+), 7 deletions(-)
> > create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> >
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index 0b767d7efa24..333d3cead0e3 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -1,4 +1,11 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> > vkms_composer.o
> > +vkms-y := \
> > + vkms_drv.o \
> > + vkms_plane.o \
> > + vkms_output.o \
> > + vkms_crtc.o \
> > + vkms_gem.o \
> > + vkms_composer.o \
> > + vkms_writeback.o
> >
> > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 387b0690a64a..656085c4ebf3 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -163,16 +163,17 @@ void vkms_composer_worker(struct work_struct *work)
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_composer *primary_composer = NULL;
> > struct vkms_composer *cursor_composer = NULL;
> > + bool crc_pending, wb_pending;
> > void *vaddr_out = NULL;
> > u32 crc32 = 0;
> > u64 frame_start, frame_end;
> > - bool crc_pending;
> > int ret;
> >
> > spin_lock_irq(>composer_lock);
> > frame_start = crtc_state->frame_start;
> > frame_end = crtc_state->frame_end;
> > crc_pending = crtc_state->crc_pending;
> > + wb_pending = crtc_state->wb_pending;
> > crtc_state->frame_start = 0;
> > crtc_state->frame_end = 0;
> > crtc_state->crc_pending = false;
> > @@ -194,22 +195,32 @@ void vkms_composer_worker(struct work_struct *work)
> > if (!primary_composer)
> > return;
> >
> > + if (wb_pending)
> > + vaddr_out = crtc_state->active_writeback;
> > +
> > ret = compose_planes(_out, primary_composer, cursor_composer);
> > if (ret) {
> > - if (ret == -EINVAL)
> > + if (ret == -EINVAL && !wb_pending)
> > kfree(vaddr_out);
> > return;
> > }
> >
> > crc32 = compute_crc(vaddr_out, primary_composer);
> >
> > + if (wb_pending) {
> > + drm_writeback_signal_completion(>wb_connector, 0);
> > + spin_lock_irq(>composer_lock);
> > + crtc_state->wb_pending = false;
> > + spin_unlock_irq(>composer_lock);
> > + } else {
> > + kfree(vaddr_out);
> > + }
> > +
> > /*
> >* The worker can fall behind the vblank hrtimer, make sure we catch
> > up.
> >*/
> > while (frame_start <= frame_end)
> > drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> > -
> > - kfree(vaddr_out);
> > }
> >
> > static const char * const pipe_crc_sources[] = {"auto"};
> > @@ -252,7 +263,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> > char *src_name,
> > return 0;
> > }
> >
> > -static void vkms_set_composer(struct vkms_output *out, bool enabled)
> > +void vkms_set_composer(struct vkms_output *out, bool enabled)
> > {
> > bool old_enabled;
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index f4036bb0b9a8..641d8bc52a3a 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #define XRES_MIN20
> > #define YRES_MIN20
> > @@
DHL
[PATCH v2] efi/efivars: Create efivars mount point via efivars abstraction
This patch creates efivars mount point when active efivars abstraction
be set. It is useful for userland to determine the availability of efivars
filesystem.
v2:
Using efivars_kobject() helper instead of checking GetVariable or
GetNextVariable EFI runtime services. Because the efivarfs code could be
instantiated using a different efivars abstraction.
Cc: Matthias Brugger
Cc: Fabian Vogt
Cc: Ilias Apalodimas
Cc: Ard Biesheuvel
Signed-off-by: "Lee, Chun-Yi"
---
drivers/firmware/efi/efi.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3aa07c3b5136..db483fc68501 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -405,11 +405,13 @@ static int __init efisubsys_init(void)
if (error)
goto err_remove_group;
- /* and the standard mountpoint for efivarfs */
- error = sysfs_create_mount_point(efi_kobj, "efivars");
- if (error) {
- pr_err("efivars: Subsystem registration failed.\n");
- goto err_remove_group;
+ if (efivars_kobject()) {
+ /* and the standard mountpoint for efivarfs */
+ error = sysfs_create_mount_point(efi_kobj, "efivars");
+ if (error) {
+ pr_err("efivars: Subsystem registration failed.\n");
+ goto err_remove_group;
+ }
}
if (efi_enabled(EFI_DBG) && efi_enabled(EFI_PRESERVE_BS_REGIONS))
--
2.16.4
Re: [PATCH] MAINTAINERS: add namespace entry
On Tue, Aug 25, 2020 at 09:01:01AM -0700, Joe Perches wrote: > On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote: > > Namespace maintainership has never been formalized which has led to > > confusion > > when people need to determine where to send patches and who should take a > > look > > at them. Especially, since we have a dedicated list > > containers.lists.linuxfoundation.org already for a long time. In > > preparation of > > this patch I added the containers.lists.linuxfoundation.org mailing list to > > be > > archived on lore. > > > > This will not just make it easier to catch and review patches specific to > > namespaces and containers but also for changes not specifically touching > > namespaces but which nevertheless will have impact on namespaces and > > containers. > > > > Add an entry for Eric (who agreed to this) and me and add a first batch of > > files that are relevant. Currently, only a small set of files are added and > > only such namespaces that haven't gotten a separate maintainers entry (e.g. > > time namespaces). I expect this to grow more entries and/or regular > > expressions > > over time. For now these entries here are sufficient. I intend to route this > > patch upstream soon. > > > > Cc: "Eric W. Biederman" > > Signed-off-by: Christian Brauner > > --- > > MAINTAINERS | 20 > > 1 file changed, 20 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index f0068bceeb61..272211cdc327 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -11892,6 +11892,26 @@ S: Supported > > W: https://www.cspi.com/ethernet-products/support/downloads/ > > F: drivers/net/ethernet/myricom/myri10ge/ > > > > +NAMESPACES AND CONTAINERS > > +M: Christian Brauner > > +M: Eric W. Biederman > > +L: containers.lists.linuxfoundation.org > > +S: Supported > > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > > +T: > > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > > +F: ipc/namespace.c > > +F: kernel/nsproxy.c > > +F: kernel/pid_namespace.c > > +F: kernel/user_namespace.c > > +F: kernel/utsname.c > > +F: include/linux/nsproxy.h > > +F: include/linux/ipc_namespace.h > > +F: include/linux/ns_common.h > > +F: include/linux/nsproxy.h > > +F: include/linux/pid_namespace.h > > +F: include/linux/user_namespace.h > > +F: include/linux/utsname.h > > Please sort the filename order alphabetically. > > F:include/linux/ipc_namespace.h > F:include/linux/ns_common.h > F:include/linux/nsproxy.h > F:include/linux/nsproxy.h > F:include/linux/pid_namespace.h > F:include/linux/user_namespace.h > F:include/linux/utsname.h > F:ipc/namespace.c > F:kernel/nsproxy.c > F:kernel/pid_namespace.c > F:kernel/user_namespace.c > F:kernel/utsname.c Thanks, fixing now. Christian
Re: [PATCH v5 1/3] dt-bindings: mmc: Add Sparx5 SDHCI controller bindings
On Tue, 25 Aug 2020 10:13:55 +0200, Lars Povlsen wrote: > The Sparx5 SDHCI controller is based on the Designware controller IP. > > Signed-off-by: Lars Povlsen > --- > .../mmc/microchip,dw-sparx5-sdhci.yaml| 65 +++ > 1 file changed, 65 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml > My bot found errors running 'make dt_binding_check' on your patch: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.example.dt.yaml: mmc0@60080: $nodename:0: 'mmc0@60080' does not match '^mmc(@.*)?$' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml See https://patchwork.ozlabs.org/patch/1350851 If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure dt-schema is up to date: pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade Please check and re-submit.
Re: [PATCH] power: supply: bq2515x: Constify static variables
Hi,
On Tue, Aug 25, 2020 at 01:22:28AM +0200, Rikard Falkeborn wrote:
> Constify a number of static variables that are not modified to allow the
> compiler to put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
Thanks, queued.
-- Sebastian
> drivers/power/supply/bq2515x_charger.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/power/supply/bq2515x_charger.c
> b/drivers/power/supply/bq2515x_charger.c
> index 36b0c8c98d40..9dcb61ea4cf2 100644
> --- a/drivers/power/supply/bq2515x_charger.c
> +++ b/drivers/power/supply/bq2515x_charger.c
> @@ -188,7 +188,7 @@ struct bq2515x_device {
> struct bq2515x_init_data init_data;
> };
>
> -static struct reg_default bq25150_reg_defaults[] = {
> +static const struct reg_default bq25150_reg_defaults[] = {
> {BQ2515X_FLAG0, 0x0},
> {BQ2515X_FLAG1, 0x0},
> {BQ2515X_FLAG2, 0x0},
> @@ -227,7 +227,7 @@ static struct reg_default bq25150_reg_defaults[] = {
> {BQ2515X_DEVICE_ID, 0x20},
> };
>
> -static struct reg_default bq25155_reg_defaults[] = {
> +static const struct reg_default bq25155_reg_defaults[] = {
> {BQ2515X_FLAG0, 0x0},
> {BQ2515X_FLAG1, 0x0},
> {BQ2515X_FLAG2, 0x0},
> @@ -886,14 +886,14 @@ static int bq2515x_battery_get_property(struct
> power_supply *psy,
> return 0;
> }
>
> -static enum power_supply_property bq2515x_battery_properties[] = {
> +static const enum power_supply_property bq2515x_battery_properties[] = {
> POWER_SUPPLY_PROP_VOLTAGE_NOW,
> POWER_SUPPLY_PROP_CURRENT_NOW,
> POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX,
> POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
> };
>
> -static enum power_supply_property bq2515x_mains_properties[] = {
> +static const enum power_supply_property bq2515x_mains_properties[] = {
> POWER_SUPPLY_PROP_ONLINE,
> POWER_SUPPLY_PROP_STATUS,
> POWER_SUPPLY_PROP_HEALTH,
> @@ -905,7 +905,7 @@ static enum power_supply_property
> bq2515x_mains_properties[] = {
> POWER_SUPPLY_PROP_PRECHARGE_CURRENT,
> };
>
> -static struct power_supply_desc bq2515x_mains_desc = {
> +static const struct power_supply_desc bq2515x_mains_desc = {
> .name = "bq2515x-mains",
> .type = POWER_SUPPLY_TYPE_MAINS,
> .get_property = bq2515x_mains_get_property,
> @@ -915,7 +915,7 @@ static struct power_supply_desc bq2515x_mains_desc = {
> .property_is_writeable = bq2515x_power_supply_property_is_writeable,
> };
>
> -static struct power_supply_desc bq2515x_battery_desc = {
> +static const struct power_supply_desc bq2515x_battery_desc = {
> .name = "bq2515x-battery",
> .type = POWER_SUPPLY_TYPE_BATTERY,
> .get_property = bq2515x_battery_get_property,
> --
> 2.28.0
>
signature.asc
Description: PGP signature
Re: [PATCH 0/3] SiFive DDR controller and EDAC support
On Tue, 25 Aug 2020 05:06:19 PDT (-0700), yash.s...@sifive.com wrote: The series add supports for SiFive DDR controller driver. This driver is use to manage the Cadence DDR controller present in SiFive SoCs. Currently it manages only the EDAC feature of the DDR controller. The series also adds Memory controller EDAC support for SiFive platform. It register for notifier event from SiFive DDR controller driver. The series is tested and based on Linux v5.8. For testing on Hifive Unleashed: 1. Enable the ECC bit of DDR controller during DDR initialization 2. Erase the entire DRAM in bootloader stage 3. Using FWC feature of DDR controller force ecc error to test Yash Shah (3): dt-bindings: riscv: Add DT documentation for DDR Controller in SiFive SoCs soc: sifive: Add SiFive specific Cadence DDR controller driver edac: sifive: Add EDAC support for Memory Controller in SiFive SoCs .../devicetree/bindings/riscv/sifive-ddr.yaml | 41 drivers/edac/Kconfig | 2 +- drivers/edac/sifive_edac.c | 117 drivers/soc/sifive/Kconfig | 6 + drivers/soc/sifive/Makefile| 3 +- drivers/soc/sifive/sifive_ddr.c| 207 + include/soc/sifive/sifive_ddr.h| 73 7 files changed, 447 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/riscv/sifive-ddr.yaml create mode 100644 drivers/soc/sifive/sifive_ddr.c create mode 100644 include/soc/sifive/sifive_ddr.h Thanks. These look good to me and I'm happy to take them through the RISC-V tree, but I'm going to wait for a bit to see if there are any comments from the maintainers of the various subsystems before doing so.
Re: [PATCH 3/3] edac: sifive: Add EDAC support for Memory Controller in SiFive SoCs
On Tue, 25 Aug 2020 05:06:22 PDT (-0700), yash.s...@sifive.com wrote:
Add Memory controller EDAC support in exisiting SiFive platform EDAC
driver. It registers for notifier events from the SiFive DDR controller
driver for DDR ECC events.
Signed-off-by: Yash Shah
---
drivers/edac/Kconfig | 2 +-
drivers/edac/sifive_edac.c | 117 +
2 files changed, 118 insertions(+), 1 deletion(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 7b6ec30..f8b3b53 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -462,7 +462,7 @@ config EDAC_ALTERA_SDMMC
config EDAC_SIFIVE
bool "Sifive platform EDAC driver"
- depends on EDAC=y && SIFIVE_L2
+ depends on EDAC=y && (SIFIVE_L2 || SIFIVE_DDR)
help
Support for error detection and correction on the SiFive SoCs.
diff --git a/drivers/edac/sifive_edac.c b/drivers/edac/sifive_edac.c
index 3a3dcb1..cf032685 100644
--- a/drivers/edac/sifive_edac.c
+++ b/drivers/edac/sifive_edac.c
@@ -11,14 +11,120 @@
#include
#include "edac_module.h"
#include
+#include
#define DRVNAME "sifive_edac"
+#define SIFIVE_EDAC_MOD_NAME "Sifive ECC Manager"
struct sifive_edac_priv {
struct notifier_block notifier;
struct edac_device_ctl_info *dci;
};
+struct sifive_edac_mc_priv {
+ struct notifier_block notifier;
+ struct mem_ctl_info *mci;
+};
+
+/**
+ * EDAC MC error callback
+ *
+ * @event: non-zero if unrecoverable.
+ */
+static
+int ecc_mc_err_event(struct notifier_block *this, unsigned long event, void
*ptr)
+{
+ struct sifive_ddr_priv *priv = ptr;
+ struct sifive_edac_mc_priv *p;
+
+ p = container_of(this, struct sifive_edac_mc_priv, notifier);
+ if (event == SIFIVE_DDR_ERR_TYPE_UE) {
+ edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, p->mci,
+priv->error_count, priv->page_frame_number,
+priv->offset_in_page, priv->syndrome,
+priv->top_layer, priv->mid_layer,
+priv->low_layer, p->mci->ctl_name, "");
+ } else if (event == SIFIVE_DDR_ERR_TYPE_CE) {
+ edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, p->mci,
+priv->error_count, priv->page_frame_number,
+priv->offset_in_page, priv->syndrome,
+priv->top_layer, priv->mid_layer,
+priv->low_layer, p->mci->ctl_name, "");
+ }
+
+ return NOTIFY_OK;
+}
+
+static int ecc_mc_register(struct platform_device *pdev)
+{
+ struct sifive_edac_mc_priv *p;
+ struct edac_mc_layer layers[1];
+ int ret;
+
+ p = devm_kzalloc(>dev, sizeof(*p), GFP_KERNEL);
+ if (!p)
+ return -ENOMEM;
+
+ p->notifier.notifier_call = ecc_mc_err_event;
+ platform_set_drvdata(pdev, p);
+
+ layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
+ layers[0].size = 1;
+ layers[0].is_virt_csrow = true;
+
+ p->mci = edac_mc_alloc(0, ARRAY_SIZE(layers), layers, 0);
+ if (!p->mci) {
+ dev_err(>dev, "Failed mem allocation for mc instance\n");
+ return -ENOMEM;
+ }
+
+ p->mci->pdev = >dev;
+ /* Initialize controller capabilities */
+ p->mci->mtype_cap = MEM_FLAG_DDR4;
+ p->mci->edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_SECDED;
+ p->mci->edac_cap = EDAC_FLAG_SECDED;
+ p->mci->scrub_cap = SCRUB_UNKNOWN;
+ p->mci->scrub_mode = SCRUB_HW_PROG;
+ p->mci->ctl_name = dev_name(>dev);
+ p->mci->dev_name = dev_name(>dev);
+ p->mci->mod_name = SIFIVE_EDAC_MOD_NAME;
+ p->mci->ctl_page_to_phys = NULL;
+
+ /* Interrupt feature is supported by cadence mc */
+ edac_op_state = EDAC_OPSTATE_INT;
+
+ ret = edac_mc_add_mc(p->mci);
+ if (ret) {
+ edac_printk(KERN_ERR, SIFIVE_EDAC_MOD_NAME,
+ "Failed to register with EDAC core\n");
+ goto err;
+ }
+
+#ifdef CONFIG_SIFIVE_DDR
+ register_sifive_ddr_error_notifier(>notifier);
+#endif
+
+ return 0;
+
+err:
+ edac_mc_free(p->mci);
+
+ return -ENXIO;
+}
+
+static int ecc_mc_unregister(struct platform_device *pdev)
+{
+ struct sifive_edac_mc_priv *p = platform_get_drvdata(pdev);
+
+#ifdef CONFIG_SIFIVE_DDR
+ unregister_sifive_ddr_error_notifier(>notifier);
+#endif
+ edac_mc_del_mc(>dev);
+ edac_mc_free(p->mci);
+
+ return 0;
+}
+
/**
* EDAC error callback
*
@@ -67,7 +173,9 @@ static int ecc_register(struct platform_device *pdev)
goto err;
}
+#ifdef CONFIG_SIFIVE_L2
register_sifive_l2_error_notifier(>notifier);
+#endif
return 0;
@@ -81,7 +189,9 @@ static int ecc_unregister(struct platform_device *pdev)
{
struct
Re: [PATCH 1/3] dt-bindings: riscv: Add DT documentation for DDR Controller in SiFive SoCs
On Tue, 25 Aug 2020 05:06:20 PDT (-0700), yash.s...@sifive.com wrote:
Add device tree bindings for SiFive FU540 DDR controller driver
Signed-off-by: Yash Shah
---
.../devicetree/bindings/riscv/sifive-ddr.yaml | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/sifive-ddr.yaml
diff --git a/Documentation/devicetree/bindings/riscv/sifive-ddr.yaml
b/Documentation/devicetree/bindings/riscv/sifive-ddr.yaml
new file mode 100644
index 000..0288119
--- /dev/null
+++ b/Documentation/devicetree/bindings/riscv/sifive-ddr.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/riscv/sifive-ddr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SiFive DDR memory controller binding
+
+description: |
+ The Sifive DDR controller driver is used to manage the Cadence DDR
+ controller present in SiFive FU540-C000 SoC. Currently the driver is
+ used to manage EDAC feature of the DDR controller.
+
+maintainers:
+ - Yash Shah
+
+properties:
+ compatible:
+enum:
+ - sifive,fu540-c000-ddr
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+memory-controller@100b {
+compatible = "sifive,fu540-c000-ddr";
+reg = <0x100b 0x4000>;
+interrupts = <31>;
+};
Reviewed-by: Palmer Dabbelt
Acked-by: Palmer Dabbelt
Re: [PATCH 2/3] soc: sifive: Add SiFive specific Cadence DDR controller driver
On Tue, 25 Aug 2020 05:06:21 PDT (-0700), yash.s...@sifive.com wrote:
Add a driver to manage the Cadence DDR controller present on SiFive SoCs
At present the driver manages the EDAC feature of the DDR controller.
Additional features may be added to the driver in future to control
other aspects of the DDR controller.
Signed-off-by: Yash Shah
---
drivers/soc/sifive/Kconfig | 6 ++
drivers/soc/sifive/Makefile | 3 +-
drivers/soc/sifive/sifive_ddr.c | 207
include/soc/sifive/sifive_ddr.h | 73 ++
4 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/sifive/sifive_ddr.c
create mode 100644 include/soc/sifive/sifive_ddr.h
diff --git a/drivers/soc/sifive/Kconfig b/drivers/soc/sifive/Kconfig
index 58cf8c4..f41d8fe 100644
--- a/drivers/soc/sifive/Kconfig
+++ b/drivers/soc/sifive/Kconfig
@@ -7,4 +7,10 @@ config SIFIVE_L2
help
Support for the L2 cache controller on SiFive platforms.
+config SIFIVE_DDR
+ bool "Sifive DDR controller driver"
+ help
+ Support for the management of cadence DDR controller on SiFive
+ platforms.
+
endif
diff --git a/drivers/soc/sifive/Makefile b/drivers/soc/sifive/Makefile
index b5caff7..b4acb5c 100644
--- a/drivers/soc/sifive/Makefile
+++ b/drivers/soc/sifive/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_SIFIVE_L2)+= sifive_l2_cache.o
+obj-$(CONFIG_SIFIVE_L2)+= sifive_l2_cache.o
+obj-$(CONFIG_SIFIVE_DDR) += sifive_ddr.o
diff --git a/drivers/soc/sifive/sifive_ddr.c b/drivers/soc/sifive/sifive_ddr.c
new file mode 100644
index 000..b1b421c
--- /dev/null
+++ b/drivers/soc/sifive/sifive_ddr.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * SiFive specific cadence DDR controller Driver
+ *
+ * Copyright (C) 2019-2020 SiFive, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static ATOMIC_NOTIFIER_HEAD(ddr_err_chain);
+
+int register_sifive_ddr_error_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(_err_chain, nb);
+}
+EXPORT_SYMBOL_GPL(register_sifive_ddr_error_notifier);
+
+int unregister_sifive_ddr_error_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_unregister(_err_chain, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_sifive_ddr_error_notifier);
+
+static void handle_ce(struct sifive_ddr_priv *pv)
+{
+ u64 err_c_addr = 0x0;
+ u64 err_c_data = 0x0;
+ u32 err_c_synd, err_c_id;
+ u32 sig_val_l, sig_val_h;
+
+ sig_val_l = readl(pv->reg + ECC_C_ADDR_L_REG);
+ sig_val_h = (readl(pv->reg + ECC_C_ADDR_H_REG) &
+ECC_ADDR_H_MASK);
+ err_c_addr = (((ulong)sig_val_h << CTL_REG_WIDTH_SHIFT) | sig_val_l);
+
+ sig_val_l = readl(pv->reg + ECC_C_DATA_L_REG);
+ sig_val_h = readl(pv->reg + ECC_C_DATA_H_REG);
+ err_c_data = (((ulong)sig_val_h << CTL_REG_WIDTH_SHIFT) | sig_val_l);
+
+ err_c_id = ((readl(pv->reg + ECC_U_C_ID_REG) &
+ECC_C_ID_MASK) >> ECC_C_ID_SHIFT);
+
+ err_c_synd = ((readl(pv->reg + ECC_C_SYND_REG) &
+ ECC_SYND_MASK) >> ECC_SYND_SHIFT);
+
+ pv->error_count = 1;
+ pv->page_frame_number = err_c_addr >> PAGE_SHIFT;
+ pv->offset_in_page = err_c_addr & ~PAGE_MASK;
+ pv->syndrome = err_c_synd;
+ pv->top_layer = 0;
+ pv->mid_layer = 0;
+ pv->low_layer = -1;
+
+ atomic_notifier_call_chain(_err_chain, SIFIVE_DDR_ERR_TYPE_CE, pv);
+}
+
+static void handle_ue(struct sifive_ddr_priv *pv)
+{
+ u64 err_u_addr = 0x0;
+ u64 err_u_data = 0x0;
+ u32 err_u_synd, err_u_id;
+ u32 sig_val_l, sig_val_h;
+
+ sig_val_l = readl(pv->reg + ECC_U_ADDR_L_REG);
+ sig_val_h = (readl(pv->reg + ECC_U_ADDR_H_REG) &
+ECC_ADDR_H_MASK);
+ err_u_addr = (((ulong)sig_val_h << CTL_REG_WIDTH_SHIFT) | sig_val_l);
+
+ sig_val_l = readl(pv->reg + ECC_U_DATA_L_REG);
+ sig_val_h = readl(pv->reg + ECC_U_DATA_H_REG);
+ err_u_data = (((ulong)sig_val_h << CTL_REG_WIDTH_SHIFT) | sig_val_l);
+
+ err_u_id = ((readl(pv->reg + ECC_U_C_ID_REG) &
+ ECC_U_ID_MASK) >> ECC_U_ID_SHIFT);
+
+ err_u_synd = ((readl(pv->reg + ECC_U_SYND_REG) &
+ ECC_SYND_MASK) >> ECC_SYND_SHIFT);
+
+ pv->error_count = 1;
+ pv->page_frame_number = err_u_addr >> PAGE_SHIFT;
+ pv->offset_in_page = err_u_addr & ~PAGE_MASK;
+ pv->syndrome = err_u_synd;
+ pv->top_layer = 0;
+ pv->mid_layer = 0;
+ pv->low_layer = -1;
+
+ atomic_notifier_call_chain(_err_chain, SIFIVE_DDR_ERR_TYPE_UE, pv);
+}
+
+static irqreturn_t ecc_isr(int irq, void *ptr)
+{
+ struct sifive_ddr_priv *pv = ptr;
+ u32 intr_status;
+ u32 val;
+
+ /* Check the intr status and confirm ECC error intr */
+
Re: [PATCH v5 0/3] drm/vkms: Introduces writeback support
Hi Rodrigo, Nice work! I tested this on the kms_writeback set of subtests and works fine. I have also checked it on the other IGT tests that I usually uses: - kms_cursor_crc/cursor-alpha-transparent was affected by a small problem in the bitmap_clear of the get_pixel_from_buffer function, that I pointed out inline. Please, check it. - kms_flip and kms_pipe_crc_basic works as expected (was not affected). Best regards, Melissa Wen On 08/24, Rodrigo Siqueira wrote: > This is the V5 version of a series that introduces the writeback support > to VKMS. The first two patches of this series are a pre-work for the > latest patch that adds the writeback connector, this patchset can be seen > in two parts: > > * A pre-work that aims to make vkms composer operations a little bit more > generic; these patches try to centralize the vkms framebuffer operations. > * The final patch enables the support for writeback in vkms. > > In the previous review, Emil suggested multiple changes in the series. I > tried to apply most of the recommendations except for some suggestions > which I was not able to incorporate due to compilation issues, or other > suggestions that may complicate this series review. I left some changes > for future patches for keeping this patchset simple with the hope of > landing this feature soon in order to support VKMS user's requirements. > Emil, let me know if you want me to change any other thing. > > It is important to highlight that from the previous series to the > current version of this patchset we had some changes in the VKMS that > made it unstable. In particular, our previous writeback series stopped > working properly due to changes in our commit tail. Thanks to Melissa > working in the instability issue and her latest fixes to VKMS, I finally > could update writeback and make it work again. The main update in the > latest patch is the use of vkms_set_composer when the writeback work > starts (enable composer) and after the writeback end (disable composer). > > Best Regard > > Rodrigo Siqueira (3): > drm/vkms: Decouple crc operations from composer > drm/vkms: Compute CRC without change input data > drm/vkms: Add support for writeback > > drivers/gpu/drm/vkms/Makefile | 9 +- > drivers/gpu/drm/vkms/vkms_composer.c | 102 +++--- > drivers/gpu/drm/vkms/vkms_drv.h | 11 +- > drivers/gpu/drm/vkms/vkms_output.c| 4 + > drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++ > 5 files changed, 231 insertions(+), 38 deletions(-) > create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c > > -- > 2.28.0 >
[net-next v5 1/2] seg6: inherit DSCP of inner IPv4 packets
This patch allows SRv6 encapsulation to inherit the DSCP value of
the inner IPv4 packet.
This allows forwarding packet across the SRv6 fabric based on their
original traffic class.
The option is controlled through a sysctl (seg6_inherit_inner_ipv4_dscp).
The sysctl has to be set to 1 to enable this feature.
Signed-off-by: Ahmed Abdelsalam
---
include/net/netns/ipv6.h | 1 +
net/ipv6/seg6_iptunnel.c | 37 -
net/ipv6/sysctl_net_ipv6.c | 9 +
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 5ec054473d81..6ed73951f479 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -50,6 +50,7 @@ struct netns_sysctl_ipv6 {
int max_dst_opts_len;
int max_hbh_opts_len;
int seg6_flowlabel;
+ bool seg6_inherit_inner_ipv4_dscp;
bool skip_notify_on_dev_down;
};
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 897fa59c47de..9cc168462e11 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -104,8 +104,7 @@ static void set_tun_src(struct net *net, struct net_device
*dev,
}
/* Compute flowlabel for outer IPv6 header */
-static __be32 seg6_make_flowlabel(struct net *net, struct sk_buff *skb,
- struct ipv6hdr *inner_hdr)
+static __be32 seg6_make_flowlabel(struct net *net, struct sk_buff *skb)
{
int do_flowlabel = net->ipv6.sysctl.seg6_flowlabel;
__be32 flowlabel = 0;
@@ -116,7 +115,7 @@ static __be32 seg6_make_flowlabel(struct net *net, struct
sk_buff *skb,
hash = rol32(hash, 16);
flowlabel = (__force __be32)hash & IPV6_FLOWLABEL_MASK;
} else if (!do_flowlabel && skb->protocol == htons(ETH_P_IPV6)) {
- flowlabel = ip6_flowlabel(inner_hdr);
+ flowlabel = ip6_flowlabel(ipv6_hdr(skb));
}
return flowlabel;
}
@@ -129,6 +128,7 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct
ipv6_sr_hdr *osrh, int proto)
struct ipv6hdr *hdr, *inner_hdr;
struct ipv6_sr_hdr *isrh;
int hdrlen, tot_len, err;
+ u8 tos = 0, hop_limit;
__be32 flowlabel;
hdrlen = (osrh->hdrlen + 1) << 3;
@@ -138,30 +138,33 @@ int seg6_do_srh_encap(struct sk_buff *skb, struct
ipv6_sr_hdr *osrh, int proto)
if (unlikely(err))
return err;
- inner_hdr = ipv6_hdr(skb);
- flowlabel = seg6_make_flowlabel(net, skb, inner_hdr);
-
- skb_push(skb, tot_len);
- skb_reset_network_header(skb);
- skb_mac_header_rebuild(skb);
- hdr = ipv6_hdr(skb);
-
/* inherit tc, flowlabel and hlim
* hlim will be decremented in ip6_forward() afterwards and
* decapsulation will overwrite inner hlim with outer hlim
*/
+ flowlabel = seg6_make_flowlabel(net, skb);
+ hop_limit = ip6_dst_hoplimit(skb_dst(skb));
+
if (skb->protocol == htons(ETH_P_IPV6)) {
- ip6_flow_hdr(hdr, ip6_tclass(ip6_flowinfo(inner_hdr)),
-flowlabel);
- hdr->hop_limit = inner_hdr->hop_limit;
+ inner_hdr = ipv6_hdr(skb);
+ hop_limit = inner_hdr->hop_limit;
+ tos = ip6_tclass(ip6_flowinfo(inner_hdr));
+ } else if (skb->protocol == htons(ETH_P_IP)) {
+ if (net->ipv6.sysctl.seg6_inherit_inner_ipv4_dscp)
+ tos = ip_hdr(skb)->tos;
+ memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
} else {
- ip6_flow_hdr(hdr, 0, flowlabel);
- hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb));
-
memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));
}
+ skb_push(skb, tot_len);
+ skb_reset_network_header(skb);
+ skb_mac_header_rebuild(skb);
+
+ hdr = ipv6_hdr(skb);
+ ip6_flow_hdr(hdr, tos, flowlabel);
+ hdr->hop_limit = hop_limit;
hdr->nexthdr = NEXTHDR_ROUTING;
isrh = (void *)hdr + sizeof(*hdr);
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index fac2135aa47b..4b2cf8764524 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -159,6 +159,15 @@ static struct ctl_table ipv6_table_template[] = {
.mode = 0644,
.proc_handler = proc_dointvec
},
+ {
+ .procname = "seg6_inherit_inner_ipv4_dscp",
+ .data =
_net.ipv6.sysctl.seg6_inherit_inner_ipv4_dscp,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = SYSCTL_ZERO,
+ .extra2 = SYSCTL_ONE,
+ },
{ }
};
--
2.17.1
Re: [PATCH] MAINTAINERS: add namespace entry
On Tue, 2020-08-25 at 17:41 +0200, Christian Brauner wrote: > Namespace maintainership has never been formalized which has led to confusion > when people need to determine where to send patches and who should take a look > at them. Especially, since we have a dedicated list > containers.lists.linuxfoundation.org already for a long time. In preparation > of > this patch I added the containers.lists.linuxfoundation.org mailing list to be > archived on lore. > > This will not just make it easier to catch and review patches specific to > namespaces and containers but also for changes not specifically touching > namespaces but which nevertheless will have impact on namespaces and > containers. > > Add an entry for Eric (who agreed to this) and me and add a first batch of > files that are relevant. Currently, only a small set of files are added and > only such namespaces that haven't gotten a separate maintainers entry (e.g. > time namespaces). I expect this to grow more entries and/or regular > expressions > over time. For now these entries here are sufficient. I intend to route this > patch upstream soon. > > Cc: "Eric W. Biederman" > Signed-off-by: Christian Brauner > --- > MAINTAINERS | 20 > 1 file changed, 20 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index f0068bceeb61..272211cdc327 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11892,6 +11892,26 @@ S: Supported > W: https://www.cspi.com/ethernet-products/support/downloads/ > F: drivers/net/ethernet/myricom/myri10ge/ > > +NAMESPACES AND CONTAINERS > +M: Christian Brauner > +M: Eric W. Biederman > +L: containers.lists.linuxfoundation.org > +S: Supported > +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ > +T: > https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ > +F: ipc/namespace.c > +F: kernel/nsproxy.c > +F: kernel/pid_namespace.c > +F: kernel/user_namespace.c > +F: kernel/utsname.c > +F: include/linux/nsproxy.h > +F: include/linux/ipc_namespace.h > +F: include/linux/ns_common.h > +F: include/linux/nsproxy.h > +F: include/linux/pid_namespace.h > +F: include/linux/user_namespace.h > +F: include/linux/utsname.h Please sort the filename order alphabetically. F: include/linux/ipc_namespace.h F: include/linux/ns_common.h F: include/linux/nsproxy.h F: include/linux/nsproxy.h F: include/linux/pid_namespace.h F: include/linux/user_namespace.h F: include/linux/utsname.h F: ipc/namespace.c F: kernel/nsproxy.c F: kernel/pid_namespace.c F: kernel/user_namespace.c F: kernel/utsname.c
Re: [net-next v5 2/2] seg6: Add documentation for seg6_inherit_inner_ipv4_dscp sysctl
On 25/08/2020 17:51, Jakub Kicinski wrote: On Tue, 25 Aug 2020 12:18:44 + Ahmed Abdelsalam wrote: + Enable the SRv6 encapsulation to inherit the DSCP value of the inner IPv4 packet. + + Default: FALSE (Do not inherit DSCP) + ``conf/default/*``: Change the interface-specific default settings. Checkpatch complains about whitespace: ERROR: trailing whitespace #24: FILE: Documentation/networking/ip-sysctl.rst:1802: +seg6_inherit_inner_ipv4_dscp - BOOLEAN $ sorry forgot to run checkpatch on this one before sending. patch fixed and resent.
RE: [PATCH 00/13] lib/generic-radix-tree: genradix bug fix and optimisations.
From: 'Marcelo Ricardo Leitner' > Sent: 25 August 2020 16:41 > > On Tue, Aug 25, 2020 at 02:52:34PM +, David Laight wrote: > > The genradix code is used by SCTP for accessing per-stream data. > > This means there are quite a lot of lookups but the code wasn't > > really optimised at all. > > My test box is down for the moment and will bring it on later today or > tomorrow, so I can't test it yet. What should we expect as performance > gains here? Not sure, probably not much, but it ought to show up :-) There'll be bigger gains on a cpu that has software ilog2(). I've only checked SCTP still works. I've requested 32k streams on a listener - to force a level-2 tree. I've also done at least one check with a massive pad in the sctp stream structure. I ought to check one of my M3UA or M2PA 'double-reflect' loopback tests. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
[net-next v5 2/2] seg6: Add documentation for seg6_inherit_inner_ipv4_dscp sysctl
This patch adds a documentation for seg6_inherit_inner_ipv4_dscp sysctl into Documentation/networking/ip-sysctl.rst Signed-off-by: Ahmed Abdelsalam --- Documentation/networking/ip-sysctl.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 837d51f9e1fa..9dacdebeafc5 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1799,6 +1799,11 @@ seg6_flowlabel - INTEGER Default is 0. +seg6_inherit_inner_ipv4_dscp - BOOLEAN + Enable the SRv6 encapsulation to inherit the DSCP value of the inner IPv4 packet. + + Default: FALSE (Do not inherit DSCP) + ``conf/default/*``: Change the interface-specific default settings. -- 2.17.1
Re: [RFC] perf/jevents: Add new structure to pass json fields.
On Tue, Aug 25, 2020 at 01:10:41PM +0530, Kajol Jain wrote: > This patch adds new structure called 'json_event' inside jevents.h > file to improve the callback prototype inside jevent files. > Initially, whenever user want to add new field, they need to update > in all function callback which make it more and more complex with > increased number of parmeters. > With this change, we just need to add it in new structure 'json_event'. Looks good to me. Thanks. I wouldn't consolidate with event_struct, these are logically different layers. Reviewed-by: Andi Kleen
Re: [PATCH v2] checkpatch: Warn if trace_printk and friends are called
On Tue, 2020-08-25 at 19:36 +0800, Nicolas Boichat wrote:
> trace_printk is meant as a debugging tool, and should not be
> compiled into production code without specific debug Kconfig
> options enabled, or source code changes, as indicated by the
> warning that shows up on boot if any trace_printk is called:
> ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
> ** **
> ** trace_printk() being used. Allocating extra memory. **
> ** **
> ** This means that this is a DEBUG kernel and it is **
> ** unsafe for production use. **
>
> Let's warn developers when they try to submit such a change.
>
> Signed-off-by: Nicolas Boichat
thanks.
> ---
> See also extensive discussion under this thread:
> https://lkml.org/lkml/2020/8/20/244
>
> This seems to be the simplest way to try to reduce the number
> of trace_printk that make it into the kernel.
>
> Changes in v2:
> - Use $1 directly, fix wording, remove final period.
>
> scripts/checkpatch.pl | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 4aa1d9d5e62c5b0..1102aa0ec2f7a05 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4272,6 +4272,12 @@ sub process {
>"Prefer dev_$level(... to dev_printk(KERN_$orig,
> ...\n" . $herecurr);
> }
>
> +# trace_printk should not be used in production code.
> + if ($line =~ /\b(trace_printk|trace_puts|ftrace_vprintk)\s*\(/)
> {
> + WARN("TRACE_PRINTK",
> + "Do not use $1() in production code (this can be
> ignored if built only with a debug config option)\n" . $herecurr);
> + }
> +
> # ENOSYS means "bad syscall nr" and nothing else. This will have a small
> # number of false positives, but assembly files are not checked, so at
> # least the arch entry code will not trigger this warning.
Re: [PATCH v2 2/5] cpufreq: intel_pstate: Always return last EPP value from sysfs
On Tue, Aug 25, 2020 at 5:27 PM Srinivas Pandruvada wrote: > > On Tue, 2020-08-25 at 17:14 +0200, Rafael J. Wysocki wrote: > > On Tue, Aug 25, 2020 at 5:06 PM Srinivas Pandruvada > > wrote: > > > On Tue, 2020-08-25 at 16:51 +0200, Rafael J. Wysocki wrote: > > > > On Tue, Aug 25, 2020 at 8:20 AM Artem Bityutskiy < > > > > dedeki...@gmail.com > > > > > wrote: > > > > > On Mon, 2020-08-24 at 19:42 +0200, Rafael J. Wysocki wrote: > > > > > > From: "Rafael J. Wysocki" > > > > > > > > > > > > Make the energy_performance_preference policy attribute in > > > > > > sysfs > > > > > > always return the last EPP value written to it instead of the > > > > > > one > > > > > > currently in the HWP Request MSR to avoid possible confusion > > > > > > when > > > > > > the performance scaling algorithm is used in the active mode > > > > > > with > > > > > > HWP enabled (in which case the EPP is forced to 0 regardless > > > > > > of > > > > > > what value it has been set to via sysfs). > > > > > > > > > > Why is this a good idea, I wonder. If there was a prior > > > > > discussion, > > > > > please, point to it. > > > > > > > > > > The general approach to changing settings via sysfs is often > > > > > like > > > > > this: > > > > > > > > > > 1. Write new value. > > > > > 2. Read it back and verify that it is the same. Because there > > > > > is no > > > > > better way to verify that the kernel "accepted" the value. > > > > > > > > If the write is successful (ie. no errors returned and the value > > > > returned is equal to the number of written characters), the > > > > kernel > > > > *has* accepted the written value, but it may not have taken > > > > effect. > > > > These are two different things. > > > > > > > > The written value may take an effect immediately or it may take > > > > an > > > > effect later, depending on the current configuration etc. If you > > > > don't see the effect of it immediately, it doesn't matter that > > > > there > > > > was a failure of some sort. > > > > > > > > > Let's say I write 'balanced' to energy_performance_preference. > > > > > I > > > > > read > > > > > it back, and it contains 'balanced', so I am happy, I trust the > > > > > kernel > > > > > changed EPP to "balanced". > > > > > > > > > > If the kernel, in fact, uses something else, I want to know > > > > > about > > > > > it > > > > > and have my script fail. > > > > > > > > Why do you want it to fail then? > > > > > > > > > Why caching the value and making my script _think_ it succeeded > > > > > is > > > > > a good idea. > > > > > > > > Because when you change the scaling algorithm or the driver's > > > > operation mode, the value you have written will take effect. > > > > > > > > In this particular case it is explained in the driver > > > > documentation > > > > that the performance scaling algorithm in the active mode > > > > overrides > > > > the sysfs value and that's the only case when it can be > > > > overridden. > > > > So whatever you write to this attribute will not take effect > > > > immediately anyway, but it may take an effect later. > > > > > > In some cases without even changing active/passive this is > > > happening > > > when there was some error previously. For example: > > > > > > #cat energy_performance_preference > > > 127 > > > [root@otcpl-perf-test-skx-i9 cpufreq]# rdmsr -p 1 0x774 > > > 8000ff00 > > > > > > I think we should show reality. In mode change can be a special > > > case > > > and use the stored value to restore in new mode. > > > > OK, so I'll make it fail on attempts to change the EPP from 0 > > (performance) in the active mode with the performance "governor". > > > Here the scaling governor is powersave. > > # cat scaling_governor > powersave What I'm saying is that reads from energy_performance_preference will still return the register value, but writes to it will fail on attempts to change to anything different from "performance" when in the active mode and the current governor is "performance". Cheers!
Re: [PATCH v3 1/2] dt-bindings: arm: at91: Add GARDENA smart Gateway (Art. 19000) board
On Sat, 22 Aug 2020 17:10:20 +0200, Reto Schneider wrote: > Document devicetree's bindings for the GARDENA smart Gateway with > article number 19000, based on the SAM9G25 Atmel SoC. Applied, thanks! I did join back the long line in the device tree documention as I found that clearer. [1/2] dt-bindings: arm: at91: Add GARDENA smart Gateway (Art. 19000) board commit: c05a4bff5c509afda0ee60009d62b5abc0e08311 [2/2] ARM: at91: Add GARDENA smart Gateway (Art. 19000) support commit: 25ffa0dde53c14cd6ddc938e39f70db4f8837591 Best regards, -- Alexandre Belloni
Re: [PATCH v3 2/2] dynamic debug: allow printing to trace event
On Tue, 2020-08-25 at 17:33 +0200, Vincent Whitchurch wrote:
> When debugging device drivers, I've found it very useful to be able to
> redirect existing pr_debug()/dev_dbg() prints to the trace buffer
> instead of dmesg. Among the many advantages of the trace buffer is that
> it can be dynamically resized, allows these prints to combined with
> other trace events, and doesn't fill up system logs.
This content should be in the 0/3 cover letter.
> Since dynamic debug already has hooks in these call sites, getting these
> prints into the ftrace buffer is straightforward if we have dynamic
> debug do it.
>
> Add an "x" flag to make the dynamic debug call site print to a new
> printk:dyndbg trace event. The trace event can be emitted instead of or
> in addition to the printk().
>
> The print buffer is statically allocated and managed using code borrowed
> from __ftrace_trace_stack() and is limited to 256 bytes (four of these
> are allocated per CPU to handle the various contexts); anything larger
> will be truncated.
There is an effort to avoid using trace_printk and the like
so perhaps this feature should have the same compile time
guard.
> Signed-off-by: Vincent Whitchurch
> ---
> .../admin-guide/dynamic-debug-howto.rst | 1 +
> include/linux/dynamic_debug.h | 4 +-
> include/trace/events/printk.h | 12 +-
> lib/dynamic_debug.c | 153 +++---
> 4 files changed, 143 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst
> b/Documentation/admin-guide/dynamic-debug-howto.rst
> index e5a8def45f3f..e717054ae142 100644
> --- a/Documentation/admin-guide/dynamic-debug-howto.rst
> +++ b/Documentation/admin-guide/dynamic-debug-howto.rst
> @@ -229,6 +229,7 @@ of the characters::
> The flags are::
>
>penables the pr_debug() callsite.
> + xenables trace to the printk:dyndbg event
>fInclude the function name in the printed message
>lInclude line number in the printed message
>mInclude module name in the printed message
> diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> index 738421898aac..74aee3f922d7 100644
> --- a/include/linux/dynamic_debug.h
> +++ b/include/linux/dynamic_debug.h
> @@ -32,7 +32,9 @@ struct _ddebug {
> #define _DPRINTK_FLAGS_INCL_FUNCNAME (1<<2)
> #define _DPRINTK_FLAGS_INCL_LINENO (1<<3)
> #define _DPRINTK_FLAGS_INCL_TID (1<<4)
> -#define _DPRINTK_FLAGS_ENABLE_DPRINTK_FLAGS_PRINTK
> +#define _DPRINTK_FLAGS_TRACE (1<<5)
> +#define _DPRINTK_FLAGS_ENABLE(_DPRINTK_FLAGS_PRINTK | \
> + _DPRINTK_FLAGS_TRACE)
> #if defined DEBUG
> #define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINTK
> #else
> diff --git a/include/trace/events/printk.h b/include/trace/events/printk.h
> index 13d405b2fd8b..1f78bd237a91 100644
> --- a/include/trace/events/printk.h
> +++ b/include/trace/events/printk.h
> @@ -7,7 +7,7 @@
>
> #include
>
> -TRACE_EVENT(console,
> +DECLARE_EVENT_CLASS(printk,
> TP_PROTO(const char *text, size_t len),
>
> TP_ARGS(text, len),
> @@ -31,6 +31,16 @@ TRACE_EVENT(console,
>
> TP_printk("%s", __get_str(msg))
> );
> +
> +DEFINE_EVENT(printk, console,
> + TP_PROTO(const char *text, size_t len),
> + TP_ARGS(text, len)
> +);
> +
> +DEFINE_EVENT(printk, dyndbg,
> + TP_PROTO(const char *text, size_t len),
> + TP_ARGS(text, len)
> +);
> #endif /* _TRACE_PRINTK_H */
>
> /* This part must be outside protection */
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 88af85cb5222..3319da2e235c 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -89,6 +90,7 @@ static struct { unsigned flag:8; char opt_char; }
> opt_array[] = {
> { _DPRINTK_FLAGS_INCL_FUNCNAME, 'f' },
> { _DPRINTK_FLAGS_INCL_LINENO, 'l' },
> { _DPRINTK_FLAGS_INCL_TID, 't' },
> + { _DPRINTK_FLAGS_TRACE, 'x' },
> { _DPRINTK_FLAGS_NONE, '_' },
> };
>
> @@ -600,6 +602,96 @@ static char *dynamic_emit_prefix(const struct _ddebug
> *desc, char *buf)
> return buf;
> }
>
> +/*
> + * This code is heavily based on __ftrace_trace_stack().
> + *
> + * Allow 4 levels of nesting: normal, softirq, irq, NMI.
> + */
> +#define DYNAMIC_TRACE_NESTING4
> +
> +struct dynamic_trace_buf {
> + char buf[256];
> +};
> +
> +struct dynamic_trace_bufs {
> + struct dynamic_trace_buf bufs[DYNAMIC_TRACE_NESTING];
> +};
> +
> +static DEFINE_PER_CPU(struct dynamic_trace_bufs, dynamic_trace_bufs);
> +static DEFINE_PER_CPU(int, dynamic_trace_reserve);
> +
> +static void dynamic_trace(const char *fmt, va_list args)
> +{
> + struct dynamic_trace_buf *buf;
> + int bufidx;
> + int len;
> +
> + preempt_disable_notrace();
> +
> + bufidx =
Re: [PATCH] sched/numa: use runnable_avg to classify node
On Tue, 25 Aug 2020 at 15:58, Mel Gorman wrote: > > On Tue, Aug 25, 2020 at 02:18:18PM +0200, Vincent Guittot wrote: > > Use runnable_avg to classify numa node state similarly to what is done for > > normal load balancer. This helps to ensure that numa and normal balancers > > use the same view of the state of the system. > > > > - large arm64system: 2 nodes / 224 CPUs > > hackbench -l (256000/#grp) -g #grp > > > > grptip/sched/core +patchset improvement > > 1 14,008(+/- 4,99 %) 13,800(+/- 3.88 %) 1,48 % > > 4 4,340(+/- 5.35 %) 4.283(+/- 4.85 %) 1,33 % > > 16 3,357(+/- 0.55 %) 3.359(+/- 0.54 %)-0,06 % > > 32 3,050(+/- 0.94 %) 3.039(+/- 1,06 %) 0,38 % > > 64 2.968(+/- 1,85 %) 3.006(+/- 2.92 %)-1.27 % > > 128 3,290(+/-12.61 %) 3,108(+/- 5.97 %) 5.51 % > > 256 3.235(+/- 3.95 %) 3,188(+/- 2.83 %) 1.45 % > > > > Intuitively the patch makes sense but I'm not a fan of using hackbench > for evaluating NUMA balancing. The tasks are too short-lived and it's > not sensitive enough to data placement because of the small footprint > and because hackbench tends to saturate a machine. > > As predicting NUMA balancing behaviour in your head can be difficult, I've > queued up a battery of tests on a few different NUMA machines and will see > what falls out. It'll take a few days as some of the tests are long-lived. Thanks for testing Mel > > Baseline will be 5.9-rc2 as I haven't looked at the topology rework in > tip/sched/core and this patch should not be related to it. looks fine to me > > -- > Mel Gorman > SUSE Labs
[PATCH] IB/qib: remove superfluous fallthrough statements
Commit 36a8f01cd24b ("IB/qib: Add congestion control agent implementation")
erroneously marked a couple of switch cases as /* FALLTHROUGH */, which
were later converted to fallthrough statements by commit df561f6688fe
("treewide: Use fallthrough pseudo-keyword"). This triggered a Coverity
warning about unreachable code.
Remove the fallthrough statements and replace the mass of gotos with
simple return statements to make the code terser and less bug-prone.
Addresses-Coverity: ("Unreachable code")
Fixes: 36a8f01cd24b ("IB/qib: Add congestion control agent implementation")
Signed-off-by: Alex Dewar
---
drivers/infiniband/hw/qib/qib_mad.c | 52 -
1 file changed, 13 insertions(+), 39 deletions(-)
diff --git a/drivers/infiniband/hw/qib/qib_mad.c
b/drivers/infiniband/hw/qib/qib_mad.c
index e7789e724f56..f83e331977f8 100644
--- a/drivers/infiniband/hw/qib/qib_mad.c
+++ b/drivers/infiniband/hw/qib/qib_mad.c
@@ -2293,76 +2293,50 @@ static int process_cc(struct ib_device *ibdev, int
mad_flags,
struct ib_mad *out_mad)
{
struct ib_cc_mad *ccp = (struct ib_cc_mad *)out_mad;
- int ret;
-
*out_mad = *in_mad;
if (ccp->class_version != 2) {
ccp->status |= IB_SMP_UNSUP_VERSION;
- ret = reply((struct ib_smp *)ccp);
- goto bail;
+ return reply((struct ib_smp *)ccp);
}
switch (ccp->method) {
case IB_MGMT_METHOD_GET:
switch (ccp->attr_id) {
case IB_CC_ATTR_CLASSPORTINFO:
- ret = cc_get_classportinfo(ccp, ibdev);
- goto bail;
-
+ return cc_get_classportinfo(ccp, ibdev);
case IB_CC_ATTR_CONGESTION_INFO:
- ret = cc_get_congestion_info(ccp, ibdev, port);
- goto bail;
-
+ return cc_get_congestion_info(ccp, ibdev, port);
case IB_CC_ATTR_CA_CONGESTION_SETTING:
- ret = cc_get_congestion_setting(ccp, ibdev, port);
- goto bail;
-
+ return cc_get_congestion_setting(ccp, ibdev, port);
case IB_CC_ATTR_CONGESTION_CONTROL_TABLE:
- ret = cc_get_congestion_control_table(ccp, ibdev, port);
- goto bail;
-
- fallthrough;
+ return cc_get_congestion_control_table(ccp, ibdev,
port);
default:
ccp->status |= IB_SMP_UNSUP_METH_ATTR;
- ret = reply((struct ib_smp *) ccp);
- goto bail;
+ return reply((struct ib_smp *) ccp);
}
-
case IB_MGMT_METHOD_SET:
switch (ccp->attr_id) {
case IB_CC_ATTR_CA_CONGESTION_SETTING:
- ret = cc_set_congestion_setting(ccp, ibdev, port);
- goto bail;
-
+ return cc_set_congestion_setting(ccp, ibdev, port);
case IB_CC_ATTR_CONGESTION_CONTROL_TABLE:
- ret = cc_set_congestion_control_table(ccp, ibdev, port);
- goto bail;
-
- fallthrough;
+ return cc_set_congestion_control_table(ccp, ibdev,
port);
default:
ccp->status |= IB_SMP_UNSUP_METH_ATTR;
- ret = reply((struct ib_smp *) ccp);
- goto bail;
+ return reply((struct ib_smp *) ccp);
}
-
case IB_MGMT_METHOD_GET_RESP:
/*
* The ib_mad module will call us to process responses
* before checking for other consumers.
* Just tell the caller to process it normally.
*/
- ret = IB_MAD_RESULT_SUCCESS;
- goto bail;
-
- case IB_MGMT_METHOD_TRAP:
- default:
- ccp->status |= IB_SMP_UNSUP_METHOD;
- ret = reply((struct ib_smp *) ccp);
+ return IB_MAD_RESULT_SUCCESS;
}
-bail:
- return ret;
+ /* method is unsupported */
+ ccp->status |= IB_SMP_UNSUP_METHOD;
+ return reply((struct ib_smp *) ccp);
}
/**
--
2.28.0
Re: [net v3 PATCH 1/2] net: ethernet: ti: cpsw: fix clean up of vlan mc entries for host port
From: Murali Karicheri
Date: Mon, 24 Aug 2020 11:10:52 -0400
> To flush the vid + mc entries from ALE, which is required when a VLAN
> interface is removed, driver needs to call cpsw_ale_flush_multicast()
> with ALE_PORT_HOST for port mask as these entries are added only for
> host port. Without this, these entries remain in the ALE table even
> after removing the VLAN interface. cpsw_ale_flush_multicast() calls
> cpsw_ale_flush_mcast which expects a port mask to do the job.
>
> Fixes: 15180eca569b ("net: ethernet: ti: cpsw: fix vlan mcast")
> Signed-off-by: Murali Karicheri
Applied and queued up for -stable.
Re: [net-next v5 2/2] seg6: Add documentation for seg6_inherit_inner_ipv4_dscp sysctl
On Tue, 25 Aug 2020 12:18:44 + Ahmed Abdelsalam wrote: > + Enable the SRv6 encapsulation to inherit the DSCP value of the inner > IPv4 packet. > > + > + Default: FALSE (Do not inherit DSCP) > + > ``conf/default/*``: > Change the interface-specific default settings. > Checkpatch complains about whitespace: ERROR: trailing whitespace #24: FILE: Documentation/networking/ip-sysctl.rst:1802: +seg6_inherit_inner_ipv4_dscp - BOOLEAN $
Re: [net v3 PATCH 2/2] net: ethernet: ti: cpsw_new: fix clean up of vlan mc entries for host port
From: Murali Karicheri
Date: Mon, 24 Aug 2020 11:10:53 -0400
> To flush the vid + mc entries from ALE, which is required when a VLAN
> interface is removed, driver needs to call cpsw_ale_flush_multicast()
> with ALE_PORT_HOST for port mask as these entries are added only for
> host port. Without this, these entries remain in the ALE table even
> after removing the VLAN interface. cpsw_ale_flush_multicast() calls
> cpsw_ale_flush_mcast which expects a port mask to do the job.
>
> Fixes: ed3525eda4c4 ("net: ethernet: ti: introduce cpsw switchdev based
> driver part 1 - dual-emac")
> Signed-off-by: Murali Karicheri
Applied and queued up for -stable.
[PATCH v2] HID: google: add google vivaldi HID driver
Add Google vivaldi HID driver. This driver allows us to read and report
the top row layout of keyboards which provide a vendor-defined HID
usage.
Signed-off-by: Sean O'Brien
---
drivers/hid/Kconfig | 9 ++
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 7 ++
drivers/hid/hid-google-vivaldi.c | 144 +++
include/linux/hid.h | 2 +
5 files changed, 163 insertions(+)
create mode 100644 drivers/hid/hid-google-vivaldi.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 05315b434276..b608a5b1d753 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -397,6 +397,15 @@ config HID_GOOGLE_HAMMER
help
Say Y here if you have a Google Hammer device.
+config HID_GOOGLE_VIVALDI
+ tristate "Google Vivaldi Keyboard"
+ depends on HID
+ help
+ Say Y here if you want to enable support for Google Vivaldi keyboards.
+
+ Vivaldi keyboards use a vendor-specific HID usage to report how the
+ keys in the top row are physically ordered.
+
config HID_GT683R
tristate "MSI GT68xR LED support"
depends on LEDS_CLASS && USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index d8ea4b8c95af..35ca714c7ee2 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
obj-$(CONFIG_HID_GFRM) += hid-gfrm.o
obj-$(CONFIG_HID_GLORIOUS) += hid-glorious.o
obj-$(CONFIG_HID_GOOGLE_HAMMER)+= hid-google-hammer.o
+obj-$(CONFIG_HID_GOOGLE_VIVALDI) += hid-google-vivaldi.o
obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 359616e3efbb..4df05b35b4d0 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -814,6 +814,13 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
if ((parser->global.usage_page << 16) >= HID_UP_MSVENDOR)
parser->scan_flags |= HID_SCAN_FLAG_VENDOR_SPECIFIC;
+
+ if ((parser->global.usage_page << 16) == HID_UP_GOOGLEVENDOR)
+ for (i = 0; i < parser->local.usage_index; i++)
+ if (parser->local.usage[i] ==
+ (HID_UP_GOOGLEVENDOR | 0x0001))
+ parser->device->group =
+ HID_GROUP_GOOGLE_VIVALDI;
}
static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)
diff --git a/drivers/hid/hid-google-vivaldi.c b/drivers/hid/hid-google-vivaldi.c
new file mode 100644
index ..9165ef5e1542
--- /dev/null
+++ b/drivers/hid/hid-google-vivaldi.c
@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * HID support for Google Vivaldi Keyboard
+ *
+ * Copyright 2020 Google LLC.
+ * Author: Sean O'Brien
+ */
+
+#include
+#include
+
+#define MIN_FN_ROW_KEY 1
+#define MAX_FN_ROW_KEY 24
+#define HID_VD_FN_ROW_PHYSMAP 0x0001
+#define HID_USAGE_FN_ROW_PHYSMAP (HID_UP_GOOGLEVENDOR | HID_VD_FN_ROW_PHYSMAP)
+
+static struct hid_driver hid_vivaldi;
+
+struct vivaldi_data {
+ u32 function_row_physmap[MAX_FN_ROW_KEY - MIN_FN_ROW_KEY + 1];
+ int max_function_row_key;
+};
+
+static ssize_t function_row_physmap_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct hid_device *hdev = to_hid_device(dev);
+ struct vivaldi_data *drvdata = hid_get_drvdata(hdev);
+ ssize_t size = 0;
+ int i;
+
+ if (!drvdata->max_function_row_key)
+ return 0;
+
+ for (i = 0; i < drvdata->max_function_row_key; i++)
+ size += sprintf(buf + size, "%02X ",
+ drvdata->function_row_physmap[i]);
+ size += sprintf(buf + size, "\n");
+ return size;
+}
+
+DEVICE_ATTR_RO(function_row_physmap);
+static struct attribute *sysfs_attrs[] = {
+ _attr_function_row_physmap.attr,
+ NULL
+};
+
+static const struct attribute_group input_attribute_group = {
+ .attrs = sysfs_attrs
+};
+
+static int vivaldi_probe(struct hid_device *hdev,
+const struct hid_device_id *id)
+{
+ struct vivaldi_data *drvdata;
+ int ret;
+
+ drvdata = devm_kzalloc(>dev, sizeof(*drvdata), GFP_KERNEL);
+ hid_set_drvdata(hdev, drvdata);
+
+ ret = hid_parse(hdev);
+ if (ret)
+ return ret;
+
+ return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+}
+
+static void vivaldi_feature_mapping(struct hid_device *hdev,
+ struct hid_field *field,
+ struct hid_usage *usage)
+{
+ struct vivaldi_data *drvdata = hid_get_drvdata(hdev);
+ int fn_key;
+ int ret;
+
Re: [PATCH v1] thermal/of: Introduce k-po, k-pu and k-i for a thermal zone
On Tue, Aug 25, 2020 at 3:44 AM Daniel Lezcano wrote: > > On 25/08/2020 10:25, Lukasz Luba wrote: > > Hi Rob, > > > > On 8/25/20 12:09 AM, Rob Herring wrote: > >> On Tue, Aug 11, 2020 at 08:31:15PM +0800, Finley Xiao wrote: > >>> The default value for k_pu is: > >>> 2 * sustainable_power / (desired_temperature - switch_on_temp) > >>> The default value for k_po is: > >>> sustainable_power / (desired_temperature - switch_on_temp) > >>> The default value for k_i is 10. > >>> > >>> Even though these parameters of the PID controller can be changed > >>> by the following sysfs files: > >>> /sys/class/thermal/thermal_zoneX/k_pu > >>> /sys/class/thermal/thermal_zoneX/k_po > >>> /sys/class/thermal/thermal_zoneX/k_i > >>> > >>> But it's still more convenient to change the default values by > >>> devicetree, > >>> so introduce these three optional properties. If provided these > >>> properties, > >>> they will be parsed and associated with the thermal zone via the thermal > >>> zone parameters. > >>> > >>> Signed-off-by: Finley Xiao > >>> --- > >>> Documentation/devicetree/bindings/thermal/thermal.txt | 14 > >>> ++ > >> > >> Bindings should be a separate file and this one is a DT schema now. > >> > >>> drivers/thermal/thermal_of.c | 7 +++ > >>> 2 files changed, 21 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt > >>> b/Documentation/devicetree/bindings/thermal/thermal.txt > >>> index f78bec19ca35..ebe936b57ded 100644 > >>> --- a/Documentation/devicetree/bindings/thermal/thermal.txt > >>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > >>> @@ -165,6 +165,20 @@ Optional property: > >>> 2000mW, while on a 10'' tablet is around > >>> 4500mW. > >>> +- k-po:Proportional parameter of the PID controller when > >>> +current temperature is above the target. > >>> + Type: signed > >>> + Size: one cell > >>> + > >>> +- k-pu:Proportional parameter of the PID controller when > >>> +current temperature is below the target. > >>> + Type: signed > >>> + Size: one cell > >>> + > >>> +- k-i:Integral parameter of the PID controller. > >>> + Type: signed > >>> + Size: one cell > >> > >> What's PID? > >> > >> I know nothing about the sysfs params, but the binding needs to stand on > >> it's own and needs enough detail to educate me. > > Sorry for the delay, I missed that patch. > > These parameters are the coefficients for the > > Proportional-Integral-Derivative (PID) controller [1], which is the > > core of the Intelligent Power Allocation (IPA) thermal governor. > > Just a few words to elaborate a bit for Rob who may not have time to > digest the whole concept from Wikipedia :) > > The PID is an regulation loop where the input is compared to the output. > > For example when driving a car and you aim a speed cruise of 90km/h. You > press the accelerator and watch the current speed. The smaller the > current speed is, the stronger you will push the accelerator. And the > closer to the cruise speed the car is, the lesser you push the > accelerator until the car stabilize to the cruise to speed. > > The k-* describes how strong you push the accelerator and release it. > > In the thermal framework, that has an impact on how brutal the > mitigation acts and depending on them it results in a flat temperature > curve or a sawtooth aspect. > > These coefficient depends on the ambient temperature (casing, room > temperature), the heat sink and the load. Depending on the use cases, > you may want to change their values at runtime. > > From my POV, setting these values in the DT does not really make sense. I pretty much always agree with not putting things in DT. :) Rob
Re: [PATCH 1/7] media: sun6i-csi: Fix the bpp for 10-bit bayer formats
On Fri, Aug 21, 2020 at 11:00 PM Kévin L'hôpital
wrote:
>
> 10-bit bayer formats are aligned to 16 bits in memory, so this is what
> needs to be used as bpp for calculating the size of the buffers to
> allocate.
>
> Signed-off-by: Kévin L'hôpital
Please add:
Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s")
> ---
> drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> index c626821aaedb..8b83d15de0d0 100644
> --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
> @@ -100,7 +100,7 @@ static inline int sun6i_csi_get_bpp(unsigned int
> pixformat)
> case V4L2_PIX_FMT_SGBRG10:
> case V4L2_PIX_FMT_SGRBG10:
> case V4L2_PIX_FMT_SRGGB10:
> - return 10;
> + return 16;
> case V4L2_PIX_FMT_SBGGR12:
> case V4L2_PIX_FMT_SGBRG12:
> case V4L2_PIX_FMT_SGRBG12:
> --
> 2.17.1
>
Re: INFO: rcu detected stall in smp_call_function
On Tue, Aug 25, 2020 at 03:24:11PM +0200, pet...@infradead.org wrote:
>
> +Cc Paul, who was weirdly forgotten last time
>
> And one additional question below, which made me remember this thing.
>
> On Wed, Jul 29, 2020 at 02:58:11PM +0200, pet...@infradead.org wrote:
>
> > > rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1):
> > > [ cut here ]
> > > IRQs not enabled as expected
> > > WARNING: CPU: 0 PID: 32297 at kernel/sched/core.c:2701
> > > try_invoke_on_locked_down_task+0x18b/0x320 kernel/sched/core.c:2701
> > > Kernel panic - not syncing: panic_on_warn set ...
> > > CPU: 0 PID: 32297 Comm: syz-executor.2 Not tainted 5.8.0-rc7-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x1f0/0x31e lib/dump_stack.c:118
> > > panic+0x264/0x7a0 kernel/panic.c:231
> > > __warn+0x227/0x250 kernel/panic.c:600
> > > report_bug+0x1b1/0x2e0 lib/bug.c:198
> > > handle_bug+0x42/0x80 arch/x86/kernel/traps.c:235
> > > exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255
> > > asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:540
> > > RIP: 0010:try_invoke_on_locked_down_task+0x18b/0x320
> > > kernel/sched/core.c:2701
> > > Code: 48 89 df e8 f7 35 09 00 4c 89 f7 e8 df b5 cf 06 e9 b5 00 00 00 c6
> > > 05 34 82 38 08 01 48 c7 c7 8c d7 07 89 31 c0 e8 a5 a9 f5 ff <0f> 0b e9 15
> > > ff ff ff 48 c7 c1 30 71 8d 89 80 e1 07 80 c1 03 38 c1
> > > RSP: 0018:c9007c50 EFLAGS: 00010046
> > > RAX: 1aaa08be6903c500 RBX: 888085d16ac8 RCX: 888085d16240
> > > RDX: 00010004 RSI: 00010004 RDI:
> > > RBP: 888085d16b0c R08: 815dd389 R09: ed1015d041c3
> > > R10: ed1015d041c3 R11: R12:
> > > R13: 8880a8bac140 R14: 8880a8bac4c0 R15: dc00
> > > rcu_print_task_stall kernel/rcu/tree_stall.h:269 [inline]
> > > print_other_cpu_stall kernel/rcu/tree_stall.h:477 [inline]
> >
> > Ha, that calls it with IRQs already disabled,
I clearly failed to test stall warnings with lockdep enabled. :-/
Good catch!
> > So I'm thinking we want something like so?
> >
> > ---
> >
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 2142c6767682..3182caf14844 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -2694,12 +2694,11 @@ try_to_wake_up(struct task_struct *p, unsigned int
> > state, int wake_flags)
> > */
> > bool try_invoke_on_locked_down_task(struct task_struct *p, bool
> > (*func)(struct task_struct *t, void *arg), void *arg)
> > {
> > - bool ret = false;
> > struct rq_flags rf;
> > + bool ret = false;
> > struct rq *rq;
> >
> > - lockdep_assert_irqs_enabled();
> > - raw_spin_lock_irq(>pi_lock);
> > + raw_spin_lock_irqsave(>pi_lock, rf.flags);
> > if (p->on_rq) {
> > rq = __task_rq_lock(p, );
> > if (task_rq(p) == rq)
> > @@ -2716,7 +2715,7 @@ bool try_invoke_on_locked_down_task(struct
> > task_struct *p, bool (*func)(struct t
> > ret = func(p, arg);
> > }
> > }
> > - raw_spin_unlock_irq(>pi_lock);
> > + raw_spin_unlock_irqrestore(>pi_lock, rf.flags);
> > return ret;
> > }
>
> Paul, I wanted to use this function, but found it has very weird
> semantics.
>
> Why do you need it to (remotely) call @func when p is current? The user
> in rcu_print_task_stall() explicitly bails in this case, and the other
> in rcu_wait_for_one_reader() will attempt an IPI.
Good question. Let me look at the invocations:
o trc_wait_for_one_reader() bails on current before
invoking try_invoke_on_locked_down_task():
if (t == current) {
t->trc_reader_checked = true;
trc_del_holdout(t);
WARN_ON_ONCE(t->trc_reader_nesting);
return;
}
o rcu_print_task_stall() might well invoke on the current task,
low though the probability of this happening might be. (The task
has to be preempted within an RCU read-side critical section
and resume in time for the scheduling-clock irq that will report
the RCU CPU stall to interrupt it.)
And you are right, no point in an IPI in this case.
> Would it be possible to change this function to:
>
> - blocked task: call @func with p->pi_lock held
> - queued, !running task: call @func with rq->lock held
> - running task: fail.
>
> ?
Why not a direct call in the current-task case, perhaps as follows,
including your change above? This would allow the RCU CPU stall
case to work naturally and without the IPI.
Would that work for your use case?
Thanx, Paul
Re: [PATCH] IMA: Handle early boot data measurement
On 8/25/20 8:40 AM, Mimi Zohar wrote: On Fri, 2020-08-21 at 16:12 -0700, Lakshmi Ramasubramanian wrote: The current implementation of early boot measurement in the IMA subsystem is very specific to asymmetric keys. It does not handle early boot measurement of data from other subsystems such as Linux Security Module (LSM), Device-Mapper, etc. As a result data, provided by these subsystems during system boot are not measured by IMA. Update the early boot key measurement to handle any early boot data. Refactor the code from ima_queue_keys.c to a new file ima_queue_data.c. Rename the kernel configuration CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS to CONFIG_IMA_QUEUE_EARLY_BOOT_DATA so it can be used for enabling any early boot data measurement. Since measurement of asymmetric keys is the first consumer of early boot measurement, this kernel configuration is enabled if IMA_MEASURE_ASYMMETRIC_KEYS and SYSTEM_TRUSTED_KEYRING are both enabled. Update the IMA hook ima_measure_critical_data() to utilize early boot measurement support. Please limit the changes in this patch to renaming the functions and/or files. For example, adding "measure_payload_hash" should be a separate patch, not hidden here. Thanks for the feedback Mimi. I'll split this into 2 patches: PATCH 1: Rename files + rename CONFIG PATCH 2: Update IMA hook to utilize early boot data measurement. -lakshmi
Re: [PATCH 1/3] dt-bindings: Add support for Broadcom USB pin map driver
+Linus W
On Tue, Aug 25, 2020 at 6:26 AM Alan Cooper wrote:
>
> On Mon, Aug 24, 2020 at 7:30 PM Rob Herring wrote:
> >
> > On Wed, Aug 12, 2020 at 04:20:16PM -0400, Al Cooper wrote:
> > > Add DT bindings for the Broadcom USB pin map driver. This driver allows
> > > some USB input and output signals to be mapped to any GPIO instead
> > > of the normal dedicated pins to/from the XHCI controller.
> >
> > Is this a driver or h/w block because bindings are for h/w blocks?
>
> This is a hardware block. I'll remove "driver" from the description.
Another question, this kind of looks like a pin mux controller. Is
that not a fit for this? If not, why?
> > > Signed-off-by: Al Cooper
> > > ---
> > > .../bindings/usb/brcm,usb-pinmap.yaml | 63 +++
> > > 1 file changed, 63 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
> > > b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
> > > new file mode 100644
> > > index ..19cf6ad36373
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml
> > > @@ -0,0 +1,63 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/usb/brcm,usb-pinmap.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Broadcom USB pin map Controller Device Tree Bindings
> > > +
> > > +maintainers:
> > > + - Al Cooper
> > > +
> > > +properties:
> > > + compatible:
> > > + items:
> > > + - const: brcm,usb-pinmap
> >
> > 2 space indentation please.
>
> Fixed.
>
> >
> > > +
> > > + reg:
> > > +maxItems: 1
> > > +
> > > + interrupts:
> > > +maxItems: 1
> > > +description: Must be defined if any out-gpios are specified.
> >
> > 'dependencies' can express this in schema.
>
> Okay.
>
> >
> > > +
> > > + in-gpios:
> > > +description: Array of one or more GPIO pins used for input signals.
> >
> > You need to define how many GPIOs are valid.
>
> I tried to avoid doing this because there is a possibility that future
> chips will have a few more signals added and the driver was written so
> new signals can be added entirely in device tree without any changes
> to the driver. If this is unacceptable, I can add the current max in
> and out valid gpios.
A 'should be enough for a while' value is fine. The driver doesn't
have to have a max. I'd expect the binding to be updated for new SoCs
anyways.
> >
> > > +
> > > + in-names:
> > > +description: Array of input signal names, one per gpio in in-gpios.
> >
> > No, this isn't how we name GPIOs. The part before '-gpios' is how.
>
> This is the meant to be a description of how each gpio is being used
> to help with error messages in the driver.
> What if I use "brcmstb,in-functions" instead?
'brcmstb' is not a vendor. But brcm,in-functions is fine.
> > > +
> > > + in-masks:
> > > +description: Array of enable and mask pairs, one per gpio in-gpios.
> >
> > Needs a vendor prefix.
>
> I'll change it to "brcmstb,in-masks"
>
> >
> > > +
> > > + out-gpios:
> > > +description: Array of one or more GPIO pins used for output signals.
> > > +
> > > + out-names:
> > > +description: Array of output signal names, one per gpio in out-gpios.
> > > +
> > > + out-masks:
> > > +description: Array of enable, value, changed and clear masks, one
> > > + per gpio in out-gpios.
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > +usb_pinmap: usb-pinmap@22000d0 {
> > > +compatible = "brcm,usb-pinmap";
> > > +reg = <0x22000d0 0x4>;
> > > +in-gpios = < 18 0>, < 19 0>;
> > > +in-names = "VBUS", "PWRFLT";
> > > +in-masks = <0x8000 0x4 0x1 0x8>;
> > > +out-gpios = < 20 0>;
> > > +out-names = "PWRON";
> > > +out-masks = <0x2 0x80 0x40 0x20>;
> > > +interrupts = <0x0 0xb2 0x4>;
> > > +};
> > > +
> > > +...
> > > --
> > > 2.17.1
> > >
Re: [PATCH v2 7/9] spi: spi-s3c64xx: Ensure cur_speed holds actual clock value
It was <2020-08-25 wto 17:11>, when Tomasz Figa wrote:
> On Tue, Aug 25, 2020 at 11:02 AM Lukasz Stelmach
> wrote:
>>
>> It was <2020-08-24 pon 15:21>, when Tomasz Figa wrote:
>> > On Mon, Aug 24, 2020 at 3:17 PM Lukasz Stelmach
>> > wrote:
>> >>
>> >> It was <2020-08-22 sob 14:43>, when Krzysztof Kozlowski wrote:
>> >> > On Fri, Aug 21, 2020 at 06:13:59PM +0200, Łukasz Stelmach wrote:
>> >> >> cur_speed is used to calculate transfer timeout and needs to be
>> >> >> set to the actual value of (half) the clock speed for precise
>> >> >> calculations.
>> >> >
>> >> > If you need this only for timeout calculation just divide it in
>> >> > s3c64xx_wait_for_dma().
>> >>
>> >> I divide it here to keep the relationship between the value the variable
>> >> holds and the one that is inside clk_* (See? It's multiplied 3 lines
>> >> above). If you look around every single clk_get_rate() call in the file is
>> >> divided by two.
>> >>
>> >> > Otherwise why only if (cmu) case is updated?
>> >>
>> >> You are righ I will update that too.
>> >>
>> >> However, I wonder if it is even possible that the value read from
>> >> S3C64XX_SPI_CLK_CFG would be different than the one written to it?
>> >>
>> >
>> > It is not possible for the register itself, but please see my other
>> > reply, where I explained the integer rounding error which can happen
>> > when calculating the value to write to the register.
>>
>> I don't have any board to test it and Marek says there is only one that
>> doesn't use cmu *and* has an SPI device attached.
>>
>> Here is what I think should work for the !cmu case.
>>
>> --8<---cut here---start->8---
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index 18b89e53ceda..5ebb1caade4d 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -655,13 +655,18 @@ static int s3c64xx_spi_config(struct
>> s3c64xx_spi_driver_data *sdd)
>> return ret;
>> sdd->cur_speed = clk_get_rate(sdd->src_clk) / 2;
>> } else {
>> + int src_clk_rate = clk_get_rate(sdd->src_clk);
>
> The return value of clk_get_rate() is unsigned long.
>
>> + int clk_val = (src_clk_rate / sdd->cur_speed / 2 - 1);
>
> Perhaps u32, since this is a value to be written to a 32-bit register.
> Also if you could add a comment explaining that a negative overflow is
> impossible:
>
> /* s3c64xx_spi_setup() ensures that sdd->cur_speed <= src_clk_rate / 2. */
OK.
> But actually, unless my lack of sleep is badly affecting my brain
> processes, the original computation was completely wrong. Let's
> consider the scenario below:
>
> src_clk_rate = 800
> sdd->cur_speed = 250
>
> clk_val = 800 / 250 / 2 - 1 = 3 / 2 - 1 = 1 - 1 = 0
> [...]
> sdd->cur_speed = 800 / (2 * (0 + 1)) = 800 / (2 * 1) = 800
> / 2 = 400
>
> So a request for 2.5 MHz ends up with 4 MHz, which could actually be
> above the client device or link spec.
>
> I believe the right thing to do would be DIV_ROUND_UP(src_clk_rate /
> 2, sdd->cur_speed) - 1. It's safe to divide src_clk_rate directly,
> because those are normally high rates divisible by two without much
> precision loss.
This makes sense.
>> +
>> /* Configure Clock */
>> val = readl(regs + S3C64XX_SPI_CLK_CFG);
>> val &= ~S3C64XX_SPI_PSR_MASK;
>> - val |= ((clk_get_rate(sdd->src_clk) / sdd->cur_speed / 2 - 1)
>> - & S3C64XX_SPI_PSR_MASK);
>> + val |= (clk_val & S3C64XX_SPI_PSR_MASK);
>> writel(val, regs + S3C64XX_SPI_CLK_CFG);
>>
>> + /* Keep the actual value */
>> + sdd->cur_speed = src_clk_rate / (2 * (clk_val + 1));
>
> Also need to consider S3C64XX_SPI_PSR_MASK here, because clk_val could
> actually be > S3C64XX_SPI_PSR_MASK.
Good point, but this
clk_val = clk_val < 127 ? clk_val : 127;
seems more appropriate since masking may give very bogus value. Eg.
src_clk_rate = 8000 // 80 MHz
cur_speed = 30 // 300 kHz
clk_val = 8000/30/2-1=> 132
clk_val &= S3C64XX_SPI_PSR_MASK => 4
cur_speed = 8000 / (2 * (4 + 1)) => 800 // 8 MHz
>> +
>> /* Enable Clock */
>> val = readl(regs + S3C64XX_SPI_CLK_CFG);
>> val |= S3C64XX_SPI_ENCLK_ENABLE;
>> --8<---cut here---end--->8---
>>
>>
>> >> > You are also affecting here not only timeout but
>> >> > s3c64xx_enable_datapath() which is not mentioned in commit log. In other
>> >> > words, this looks wrong.
>> >>
>> >> Indeed, there is a reference too. I've corrected the message.
>> >>
>> >
>> > Thanks!
>> >
>> > Best regards,
>> > Tomasz
>> >
>> >> >>
>> >> >> Cc: Tomasz Figa
>> >> >> Signed-off-by: Łukasz Stelmach
>> >> >> ---
>> >> >> drivers/spi/spi-s3c64xx.c | 1 +
>> >> >> 1 file changed, 1 insertion(+)
>>
Re: [PATCH v5 3/3] drm/vkms: Add support for writeback
On 08/24, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don't
> have hardware with writeback support.
>
> Change in V4 (Emil and Melissa):
> - Move signal completion above drm_crtc_add_crc_entry()
> - Make writeback always available
> - Use appropriate namespace
> - Drop fb check in vkms_wb_atomic_commit
> - Make vkms_set_composer visible for writeback code
> - Enable composer operation on prepare_job and disable it on cleanup_job
>
> Change in V3 (Daniel):
> - If writeback is enabled, compose everything into the writeback buffer
> instead of CRC private buffer
> - Guarantees that the CRC will match exactly what we have in the
> writeback buffer.
>
> Change in V2:
> - Rework signal completion (Brian)
> - Integrates writeback with active_planes (Daniel)
> - Compose cursor (Daniel)
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/Makefile | 9 +-
> drivers/gpu/drm/vkms/vkms_composer.c | 21 +++-
> drivers/gpu/drm/vkms/vkms_drv.h | 11 +-
> drivers/gpu/drm/vkms/vkms_output.c| 4 +
> drivers/gpu/drm/vkms/vkms_writeback.c | 143 ++
> 5 files changed, 181 insertions(+), 7 deletions(-)
> create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
>
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 0b767d7efa24..333d3cead0e3 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -1,4 +1,11 @@
> # SPDX-License-Identifier: GPL-2.0-only
> -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> vkms_composer.o
> +vkms-y := \
> + vkms_drv.o \
> + vkms_plane.o \
> + vkms_output.o \
> + vkms_crtc.o \
> + vkms_gem.o \
> + vkms_composer.o \
> + vkms_writeback.o
>
> obj-$(CONFIG_DRM_VKMS) += vkms.o
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 387b0690a64a..656085c4ebf3 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -163,16 +163,17 @@ void vkms_composer_worker(struct work_struct *work)
> struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> struct vkms_composer *primary_composer = NULL;
> struct vkms_composer *cursor_composer = NULL;
> + bool crc_pending, wb_pending;
> void *vaddr_out = NULL;
> u32 crc32 = 0;
> u64 frame_start, frame_end;
> - bool crc_pending;
> int ret;
>
> spin_lock_irq(>composer_lock);
> frame_start = crtc_state->frame_start;
> frame_end = crtc_state->frame_end;
> crc_pending = crtc_state->crc_pending;
> + wb_pending = crtc_state->wb_pending;
> crtc_state->frame_start = 0;
> crtc_state->frame_end = 0;
> crtc_state->crc_pending = false;
> @@ -194,22 +195,32 @@ void vkms_composer_worker(struct work_struct *work)
> if (!primary_composer)
> return;
>
> + if (wb_pending)
> + vaddr_out = crtc_state->active_writeback;
> +
> ret = compose_planes(_out, primary_composer, cursor_composer);
> if (ret) {
> - if (ret == -EINVAL)
> + if (ret == -EINVAL && !wb_pending)
> kfree(vaddr_out);
> return;
> }
>
> crc32 = compute_crc(vaddr_out, primary_composer);
>
> + if (wb_pending) {
> + drm_writeback_signal_completion(>wb_connector, 0);
> + spin_lock_irq(>composer_lock);
> + crtc_state->wb_pending = false;
> + spin_unlock_irq(>composer_lock);
> + } else {
> + kfree(vaddr_out);
> + }
> +
> /*
>* The worker can fall behind the vblank hrtimer, make sure we catch up.
>*/
> while (frame_start <= frame_end)
> drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> -
> - kfree(vaddr_out);
> }
>
> static const char * const pipe_crc_sources[] = {"auto"};
> @@ -252,7 +263,7 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const
> char *src_name,
> return 0;
> }
>
> -static void vkms_set_composer(struct vkms_output *out, bool enabled)
> +void vkms_set_composer(struct vkms_output *out, bool enabled)
> {
> bool old_enabled;
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
> index f4036bb0b9a8..641d8bc52a3a 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.h
> +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
>
> #define XRES_MIN20
> #define YRES_MIN20
> @@ -19,6 +20,7 @@
> #define YRES_MAX 8192
>
> extern bool enable_cursor;
> +extern bool enable_writeback;
>
> struct vkms_composer {
> struct drm_framebuffer fb;
> @@ -52,9 +54,11 @@ struct vkms_crtc_state {
> int num_active_planes;
> /* stack of active planes for crc computation, should
Re: [PATCH v2] kobject: Restore old behaviour of kobject_del(NULL)
On Tue, Aug 25, 2020 at 05:41:09PM +0300, Andy Shevchenko wrote:
> On Mon, Aug 03, 2020 at 11:46:59AM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Aug 03, 2020 at 11:27:06AM +0300, Andy Shevchenko wrote:
> > > The commit 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing
> > > in
> > > kobject_cleanup()") inadvertently dropped a possibility to call
> > > kobject_del()
> > > with NULL pointer. Restore the old behaviour.
> > >
> > > Fixes: 079ad2fb4bf9 ("kobject: Avoid premature parent object freeing in
> > > kobject_cleanup()")
> > > Reported-by: Qu Wenruo
> > > Cc: Heikki Krogerus
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > v2: replaced ?: with plain conditional (Greg)
> > > lib/kobject.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > Thanks, much better, will queue up after -rc1 is out.
>
> Shouldn't be this taken care of?
Yes, will get to it soon, after -rc1 is tough, combined with Plumbers...
greg k-h
[PATCH] USB: integrate macro definitions into include/linux/usb.h
From: Yanfei Xu include/linux/usb.h also contains 'Hard limit' and 'Arbitrary limit' macro definitions in it, hence we can integrate these from config.c into include/linux/usb.h Signed-off-by: Yanfei Xu --- drivers/usb/core/config.c | 3 --- include/linux/usb.h | 3 +++ 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c index 562a730befda..58c5d946cd86 100644 --- a/drivers/usb/core/config.c +++ b/drivers/usb/core/config.c @@ -14,9 +14,6 @@ #include "usb.h" -#define USB_MAXALTSETTING 128 /* Hard limit */ - -#define USB_MAXCONFIG 8 /* Arbitrary limit */ static inline const char *plural(int n) diff --git a/include/linux/usb.h b/include/linux/usb.h index 20c555db4621..d0a117cfc6bd 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -275,9 +275,12 @@ void usb_put_intf(struct usb_interface *intf); /* Hard limit */ #define USB_MAXENDPOINTS 30 +#define USB_MAXALTSETTING 128 + /* this maximum is arbitrary */ #define USB_MAXINTERFACES 32 #define USB_MAXIADS(USB_MAXINTERFACES/2) +#define USB_MAXCONFIG 8 /* * USB Resume Timer: Every Host controller driver should drive the resume -- 2.18.2
Re: [PATCH v2 1/1] mm, oom_adj: don't loop through tasks in __set_oom_adj when not necessary
On 08/25, Michal Hocko wrote: > > Btw. now that the flag is in place we can optimize __oom_kill_process as > well. and zap_threads(). Oleg.
Re: [PATCH] net: usb: Fix uninit-was-stored issue in asix_read_cmd()
On Tue, Aug 25, 2020 at 04:44:37PM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 25, 2020 at 10:39:46AM -0400, Alan Stern wrote: > > On Tue, Aug 25, 2020 at 08:51:35AM +0200, Greg Kroah-Hartman wrote: > > > At first glance, I think this can all be cleaned up, but it will take a > > > bit of tree-wide work. I agree, we need a "read this message and error > > > if the whole thing is not there", as well as a "send this message and > > > error if the whole thing was not sent", and also a way to handle > > > stack-provided data, which seems to be the primary reason subsystems > > > wrap this call (they want to make it easier on their drivers to use it.) > > > > > > Let me think about this in more detail, but maybe something like: > > > usb_control_msg_read() > > > usb_control_msg_send() > > > is a good first step (as the caller knows this) and stack provided data > > > would be allowed, and it would return an error if the whole message was > > > not read/sent properly. That way we can start converting everything > > > over to a sane, and checkable, api and remove a bunch of wrapper > > > functions as well. > > > > Suggestion: _read and _send are not a natural pair. Consider instead > > _read and _write. _recv and _send don't feel right either, because it > > both cases the host sends the control message -- the difference lies > > in who sends the data. > > Yes, naming is hard :) > > usb_control_read_msg() > usb_control_write_msg() > > feels good to me, let me try this out and see if it actually makes sense > to do this on a few in-usb-core files and various drivers... Turns out we have a long history of using snd/rcv for USB control messages: usb_rcvctrlpipe() usb_sndctrlpipe() so while _recv and _send might feel a bit "odd", it is what we are used to using, and when converting existing users, I can drop the pipe macro from the calls, turning something like: usb_control_msg(hdev, usb_sndctrlpipe(hdev, 0), ...); into: usb_control_send_msg(hdev, 0, ...); or maybe: usb_control_msg_send(hdev, 0, ...); with a full noun_verb pairing, instead of noun_verb_noun. thanks, greg k-h
[PATCH] iommu: Add support to filter non-strict/lazy mode based on device names
Currently the non-strict or lazy mode of TLB invalidation can only be set
for all or no domains. This works well for development platforms where
setting to non-strict/lazy mode is fine for performance reasons but on
production devices, we need a more fine grained control to allow only
certain peripherals to support this mode where we can be sure that it is
safe. So add support to filter non-strict/lazy mode based on the device
names that are passed via cmdline parameter "iommu.nonstrict_device".
Example: iommu.nonstrict_device="7c4000.sdhci,a60.dwc3,6048000.etr"
Signed-off-by: Sai Prakash Ranjan
---
drivers/iommu/iommu.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 609bd25bf154..fd10a073f557 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,9 @@ static unsigned int iommu_def_domain_type __read_mostly;
static bool iommu_dma_strict __read_mostly = true;
static u32 iommu_cmd_line __read_mostly;
+#define DEVICE_NAME_LEN1024
+static char nonstrict_device[DEVICE_NAME_LEN] __read_mostly;
+
struct iommu_group {
struct kobject kobj;
struct kobject *devices_kobj;
@@ -327,6 +330,32 @@ static int __init iommu_dma_setup(char *str)
}
early_param("iommu.strict", iommu_dma_setup);
+static int __init iommu_nonstrict_filter_setup(char *str)
+{
+ strlcpy(nonstrict_device, str, DEVICE_NAME_LEN);
+ return 1;
+}
+__setup("iommu.nonstrict_device=", iommu_nonstrict_filter_setup);
+
+static bool iommu_nonstrict_device(struct device *dev)
+{
+ char *filter, *device;
+
+ if (!dev)
+ return false;
+
+ filter = kstrdup(nonstrict_device, GFP_KERNEL);
+ if (!filter)
+ return false;
+
+ while ((device = strsep(, ","))) {
+ if (!strcmp(device, dev_name(dev)))
+ return true;
+ }
+
+ return false;
+}
+
static ssize_t iommu_group_attr_show(struct kobject *kobj,
struct attribute *__attr, char *buf)
{
@@ -1470,7 +1499,7 @@ static int iommu_get_def_domain_type(struct device *dev)
static int iommu_group_alloc_default_domain(struct bus_type *bus,
struct iommu_group *group,
- unsigned int type)
+ unsigned int type, struct device
*dev)
{
struct iommu_domain *dom;
@@ -1489,7 +1518,7 @@ static int iommu_group_alloc_default_domain(struct
bus_type *bus,
if (!group->domain)
group->domain = dom;
- if (!iommu_dma_strict) {
+ if (!iommu_dma_strict || iommu_nonstrict_device(dev)) {
int attr = 1;
iommu_domain_set_attr(dom,
DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE,
@@ -1509,7 +1538,7 @@ static int iommu_alloc_default_domain(struct iommu_group
*group,
type = iommu_get_def_domain_type(dev);
- return iommu_group_alloc_default_domain(dev->bus, group, type);
+ return iommu_group_alloc_default_domain(dev->bus, group, type, dev);
}
/**
@@ -1684,7 +1713,7 @@ static void probe_alloc_default_domain(struct bus_type
*bus,
if (!gtype.type)
gtype.type = iommu_def_domain_type;
- iommu_group_alloc_default_domain(bus, group, gtype.type);
+ iommu_group_alloc_default_domain(bus, group, gtype.type, NULL);
}
base-commit: e46b3c0d011eab9933c183d5b47569db8e377281
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v5 2/3] drm/vkms: Compute CRC without change input data
On 08/24, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the input
> framebuffer, which is not a problem since this function receives a copy
> of the original buffer. However, if we want to use this function in a
> context without a buffer copy, it will change the initial value. This
> patch makes compute_crc() calculate the CRC value without modifying the
> input framebuffer.
>
> Change in V4 (Emil):
> - Move bitmap_clear operation and comments to get_pixel function
>
> Signed-off-by: Rodrigo Siqueira
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 38 ++--
> 1 file changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index 4d8bc04bb6ee..387b0690a64a 100644
> --- a/drivers/gpu/drm/vkms/vkms_composer.c
> +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> @@ -9,33 +9,43 @@
>
> #include "vkms_drv.h"
>
> +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> + const struct vkms_composer *composer)
> +{
> + u32 pixel;
> + int src_offset = composer->offset + (y * composer->pitch)
> + + (x * composer->cpp);
> +
> + pixel = *(u32 *)[src_offset];
> + /* XRGB format ignores Alpha channel */
> + bitmap_clear((void *), 0, 8);
I noticed a small problem in this bitmap_clear as I recently sent a
patch changing it. The starting point for zeroing the alpha is not 0,
but 24. As in the removed line below:
- bitmap_clear(vaddr_out + src_offset, 24, 8);
It affects the kms_cursor_crc/cursor-alpha-transparent subtest.
> +
> + return pixel;
> +}
> +
> /**
> * compute_crc - Compute CRC value on output frame
> *
> - * @vaddr_out: address to final framebuffer
> + * @vaddr: address to final framebuffer
> * @composer: framebuffer's metadata
> *
> * returns CRC value computed using crc32 on the visible portion of
> * the final framebuffer at vaddr_out
> */
> -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer *composer)
> +static uint32_t compute_crc(const u8 *vaddr,
> + const struct vkms_composer *composer)
> {
> - int i, j, src_offset;
> + int x, y;
> + u32 crc = 0, pixel = 0;
> int x_src = composer->src.x1 >> 16;
> int y_src = composer->src.y1 >> 16;
> int h_src = drm_rect_height(>src) >> 16;
> int w_src = drm_rect_width(>src) >> 16;
> - u32 crc = 0;
> -
> - for (i = y_src; i < y_src + h_src; ++i) {
> - for (j = x_src; j < x_src + w_src; ++j) {
> - src_offset = composer->offset
> - + (i * composer->pitch)
> - + (j * composer->cpp);
> - /* XRGB format ignores Alpha channel */
> - bitmap_clear(vaddr_out + src_offset, 24, 8);
> - crc = crc32_le(crc, vaddr_out + src_offset,
> -sizeof(u32));
> +
> + for (y = y_src; y < y_src + h_src; ++y) {
> + for (x = x_src; x < x_src + w_src; ++x) {
> + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> + crc = crc32_le(crc, (void *), sizeof(u32));
> }
> }
>
> --
> 2.28.0
>
[PATCH] MAINTAINERS: add namespace entry
Namespace maintainership has never been formalized which has led to confusion when people need to determine where to send patches and who should take a look at them. Especially, since we have a dedicated list containers.lists.linuxfoundation.org already for a long time. In preparation of this patch I added the containers.lists.linuxfoundation.org mailing list to be archived on lore. This will not just make it easier to catch and review patches specific to namespaces and containers but also for changes not specifically touching namespaces but which nevertheless will have impact on namespaces and containers. Add an entry for Eric (who agreed to this) and me and add a first batch of files that are relevant. Currently, only a small set of files are added and only such namespaces that haven't gotten a separate maintainers entry (e.g. time namespaces). I expect this to grow more entries and/or regular expressions over time. For now these entries here are sufficient. I intend to route this patch upstream soon. Cc: "Eric W. Biederman" Signed-off-by: Christian Brauner --- MAINTAINERS | 20 1 file changed, 20 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index f0068bceeb61..272211cdc327 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11892,6 +11892,26 @@ S: Supported W: https://www.cspi.com/ethernet-products/support/downloads/ F: drivers/net/ethernet/myricom/myri10ge/ +NAMESPACES AND CONTAINERS +M: Christian Brauner +M: Eric W. Biederman +L: containers.lists.linuxfoundation.org +S: Supported +T: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/ +T: https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/ +F: ipc/namespace.c +F: kernel/nsproxy.c +F: kernel/pid_namespace.c +F: kernel/user_namespace.c +F: kernel/utsname.c +F: include/linux/nsproxy.h +F: include/linux/ipc_namespace.h +F: include/linux/ns_common.h +F: include/linux/nsproxy.h +F: include/linux/pid_namespace.h +F: include/linux/user_namespace.h +F: include/linux/utsname.h + NAND FLASH SUBSYSTEM M: Miquel Raynal R: Richard Weinberger base-commit: d012a7190fc1fd72ed48911e77ca97ba4521bccd -- 2.28.0
Re: [PATCH 00/13] lib/generic-radix-tree: genradix bug fix and optimisations.
On Tue, Aug 25, 2020 at 02:52:34PM +, David Laight wrote: > The genradix code is used by SCTP for accessing per-stream data. > This means there are quite a lot of lookups but the code wasn't > really optimised at all. My test box is down for the moment and will bring it on later today or tomorrow, so I can't test it yet. What should we expect as performance gains here? Marcelo
Re: [PATCH] IMA: Handle early boot data measurement
On Fri, 2020-08-21 at 16:12 -0700, Lakshmi Ramasubramanian wrote: > The current implementation of early boot measurement in > the IMA subsystem is very specific to asymmetric keys. It does not > handle early boot measurement of data from other subsystems such as > Linux Security Module (LSM), Device-Mapper, etc. As a result data, > provided by these subsystems during system boot are not measured by IMA. > > Update the early boot key measurement to handle any early boot data. > Refactor the code from ima_queue_keys.c to a new file ima_queue_data.c. > Rename the kernel configuration CONFIG_IMA_QUEUE_EARLY_BOOT_KEYS to > CONFIG_IMA_QUEUE_EARLY_BOOT_DATA so it can be used for enabling any > early boot data measurement. Since measurement of asymmetric keys is > the first consumer of early boot measurement, this kernel configuration > is enabled if IMA_MEASURE_ASYMMETRIC_KEYS and SYSTEM_TRUSTED_KEYRING are > both enabled. > > Update the IMA hook ima_measure_critical_data() to utilize early boot > measurement support. Please limit the changes in this patch to renaming the functions and/or files. For example, adding "measure_payload_hash" should be a separate patch, not hidden here. Mimi
