[PATCH RFC 5/5] vdpasim: support batch updating
The vDPA simulator support both set_map() and dma_map()/dma_unmap()
operations. But vhost-vdpa can only use one of them. So this patch
introduce a module parameter (batch_mapping) that let vpda_sim to
support only one of those dma operations. The batched mapping via
set_map() is enabled by default.
Signed-off-by: Jason Wang
---
drivers/vdpa/vdpa_sim/vdpa_sim.c | 40 +---
1 file changed, 37 insertions(+), 3 deletions(-)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index c7334cc65bb2..a7a0962ed8a8 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -33,6 +33,10 @@
#define DRV_DESC "vDPA Device Simulator"
#define DRV_LICENSE "GPL v2"
+static int batch_mapping = 1;
+module_param(batch_mapping, int, 0444);
+MODULE_PARM_DESC(batch_mapping, "Batched mapping 1 -Enable; 0 - Disable");
+
struct vdpasim_virtqueue {
struct vringh vring;
struct vringh_kiov iov;
@@ -303,16 +307,22 @@ static const struct dma_map_ops vdpasim_dma_ops = {
};
static const struct vdpa_config_ops vdpasim_net_config_ops;
+static const struct vdpa_config_ops vdpasim_net_batch_config_ops;
static struct vdpasim *vdpasim_create(void)
{
+ const struct vdpa_config_ops *ops;
struct virtio_net_config *config;
struct vdpasim *vdpasim;
struct device *dev;
int ret = -ENOMEM;
- vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL,
- _net_config_ops);
+ if (batch_mapping)
+ ops = _net_batch_config_ops;
+ else
+ ops = _net_config_ops;
+
+ vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops);
if (!vdpasim)
goto err_alloc;
@@ -597,12 +607,36 @@ static const struct vdpa_config_ops
vdpasim_net_config_ops = {
.get_config = vdpasim_get_config,
.set_config = vdpasim_set_config,
.get_generation = vdpasim_get_generation,
- .set_map= vdpasim_set_map,
.dma_map= vdpasim_dma_map,
.dma_unmap = vdpasim_dma_unmap,
.free = vdpasim_free,
};
+static const struct vdpa_config_ops vdpasim_net_batch_config_ops = {
+ .set_vq_address = vdpasim_set_vq_address,
+ .set_vq_num = vdpasim_set_vq_num,
+ .kick_vq= vdpasim_kick_vq,
+ .set_vq_cb = vdpasim_set_vq_cb,
+ .set_vq_ready = vdpasim_set_vq_ready,
+ .get_vq_ready = vdpasim_get_vq_ready,
+ .set_vq_state = vdpasim_set_vq_state,
+ .get_vq_state = vdpasim_get_vq_state,
+ .get_vq_align = vdpasim_get_vq_align,
+ .get_features = vdpasim_get_features,
+ .set_features = vdpasim_set_features,
+ .set_config_cb = vdpasim_set_config_cb,
+ .get_vq_num_max = vdpasim_get_vq_num_max,
+ .get_device_id = vdpasim_get_device_id,
+ .get_vendor_id = vdpasim_get_vendor_id,
+ .get_status = vdpasim_get_status,
+ .set_status = vdpasim_set_status,
+ .get_config = vdpasim_get_config,
+ .set_config = vdpasim_set_config,
+ .get_generation = vdpasim_get_generation,
+ .set_map= vdpasim_set_map,
+ .free = vdpasim_free,
+};
+
static int __init vdpasim_dev_init(void)
{
vdpasim_dev = vdpasim_create();
--
2.20.1
[PATCH RFC 4/5] vhost-vdpa: support IOTLB batching hints
This patches extend the vhost IOTLB API to accept batch updating hints
form userspace. When userspace wants update the device IOTLB in a
batch, it may do:
1) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_BEGIN flag
2) Perform a batch of IOTLB updating via VHOST_IOTLB_UPDATE/INVALIDATE
3) Write vhost_iotlb_msg with VHOST_IOTLB_BATCH_END flag
Vhost-vdpa may decide to batch the IOMMU/IOTLB updating in step 3 when
vDPA device support set_map() ops. This is useful for the vDPA device
that want to know all the mappings to tweak their own DMA translation
logic.
For vDPA device that doesn't require set_map(), no behavior changes.
This capability is advertised via VHOST_BACKEND_F_IOTLB_BATCH capability.
Signed-off-by: Jason Wang
---
drivers/vhost/vdpa.c | 30 +++---
include/uapi/linux/vhost.h | 2 ++
include/uapi/linux/vhost_types.h | 7 +++
3 files changed, 32 insertions(+), 7 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 453057421f80..8f624bbafee7 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -56,7 +56,9 @@ enum {
};
enum {
- VHOST_VDPA_BACKEND_FEATURES = (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2)
+ VHOST_VDPA_BACKEND_FEATURES =
+ (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2) |
+ (1ULL << VHOST_BACKEND_F_IOTLB_BATCH),
};
/* Currently, only network backend w/o multiqueue is supported. */
@@ -77,6 +79,7 @@ struct vhost_vdpa {
int virtio_id;
int minor;
struct eventfd_ctx *config_ctx;
+ int in_batch;
};
static DEFINE_IDA(vhost_vdpa_ida);
@@ -125,6 +128,7 @@ static void vhost_vdpa_reset(struct vhost_vdpa *v)
const struct vdpa_config_ops *ops = vdpa->config;
ops->set_status(vdpa, 0);
+ v->in_batch = 0;
}
static long vhost_vdpa_get_device_id(struct vhost_vdpa *v, u8 __user *argp)
@@ -540,9 +544,10 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
if (ops->dma_map)
r = ops->dma_map(vdpa, iova, size, pa, perm);
- else if (ops->set_map)
- r = ops->set_map(vdpa, dev->iotlb);
- else
+ else if (ops->set_map) {
+ if (!v->in_batch)
+ r = ops->set_map(vdpa, dev->iotlb);
+ } else
r = iommu_map(v->domain, iova, pa, size,
perm_to_iommu_flags(perm));
@@ -559,9 +564,10 @@ static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64
iova, u64 size)
if (ops->dma_map)
ops->dma_unmap(vdpa, iova, size);
- else if (ops->set_map)
- ops->set_map(vdpa, dev->iotlb);
- else
+ else if (ops->set_map) {
+ if (!v->in_batch)
+ ops->set_map(vdpa, dev->iotlb);
+ } else
iommu_unmap(v->domain, iova, size);
}
@@ -655,6 +661,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev
*dev,
struct vhost_iotlb_msg *msg)
{
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
+ struct vdpa_device *vdpa = v->vdpa;
+ const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
r = vhost_dev_check_owner(dev);
@@ -668,6 +676,14 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev
*dev,
case VHOST_IOTLB_INVALIDATE:
vhost_vdpa_unmap(v, msg->iova, msg->size);
break;
+ case VHOST_IOTLB_BATCH_BEGIN:
+ v->in_batch = true;
+ break;
+ case VHOST_IOTLB_BATCH_END:
+ if (v->in_batch && ops->set_map)
+ ops->set_map(vdpa, dev->iotlb);
+ v->in_batch = false;
+ break;
default:
r = -EINVAL;
break;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 0c2349612e77..565da96f55d5 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -91,6 +91,8 @@
/* Use message type V2 */
#define VHOST_BACKEND_F_IOTLB_MSG_V2 0x1
+/* IOTLB can accpet batching hints */
+#define VHOST_BACKEND_F_IOTLB_BATCH 0x2
#define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
#define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index 669457ce5c48..5c12faffdde9 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -60,6 +60,13 @@ struct vhost_iotlb_msg {
#define VHOST_IOTLB_UPDATE 2
#define VHOST_IOTLB_INVALIDATE 3
#define VHOST_IOTLB_ACCESS_FAIL4
+/* VHOST_IOTLB_BATCH_BEGIN is a hint that userspace will update
+ * several mappings afterwards. VHOST_IOTLB_BATCH_END is a hint that
+ * userspace had finished the mapping updating. When those two flags
+ * were set, kernel will ignore the rest fileds of the IOTLB message.
+ */
+#define VHOST_IOTLB_BATCH_BEGIN5
+#define
[PATCH RFC 3/5] vhost-vdpa: support get/set backend features
This patch makes userspace can get and set backend features to
vhost-vdpa.
Signed-off-by: Cindy Lu
Signed-off-by: Jason Wang
---
drivers/vhost/vdpa.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index db4c9cb44c61..453057421f80 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -55,6 +55,10 @@ enum {
(1ULL << VIRTIO_NET_F_SPEED_DUPLEX),
};
+enum {
+ VHOST_VDPA_BACKEND_FEATURES = (1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2)
+};
+
/* Currently, only network backend w/o multiqueue is supported. */
#define VHOST_VDPA_VQ_MAX 2
@@ -340,6 +344,8 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v,
unsigned int cmd,
struct vdpa_callback cb;
struct vhost_virtqueue *vq;
struct vhost_vring_state s;
+ u64 __user *featurep = argp;
+ u64 features;
u32 idx;
long r;
@@ -362,6 +368,18 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v,
unsigned int cmd,
case VHOST_GET_VRING_BASE:
vq->last_avail_idx = ops->get_vq_state(v->vdpa, idx);
break;
+ case VHOST_GET_BACKEND_FEATURES:
+ features = VHOST_VDPA_BACKEND_FEATURES;
+ if (copy_to_user(featurep, , sizeof(features)))
+ return -EFAULT;
+ return 0;
+ case VHOST_SET_BACKEND_FEATURES:
+ if (copy_from_user(, featurep, sizeof(features)))
+ return -EFAULT;
+ if (features & ~VHOST_VDPA_BACKEND_FEATURES)
+ return -EOPNOTSUPP;
+ vhost_set_backend_features(>vdev, features);
+ return 0;
}
r = vhost_vring_ioctl(>vdev, cmd, argp);
--
2.20.1
[PATCH RFC 2/5] vhost: generialize backend features setting/getting
Move the backend features setting/getting from net.c to vhost.c to be
reused by vhost-vdpa.
Signed-off-by: Jason Wang
---
drivers/vhost/net.c | 18 ++
drivers/vhost/vhost.c | 15 +++
drivers/vhost/vhost.h | 2 ++
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 0b509be8d7b1..d88afe3f6060 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1622,21 +1622,6 @@ static long vhost_net_reset_owner(struct vhost_net *n)
return err;
}
-static int vhost_net_set_backend_features(struct vhost_net *n, u64 features)
-{
- int i;
-
- mutex_lock(>dev.mutex);
- for (i = 0; i < VHOST_NET_VQ_MAX; ++i) {
- mutex_lock(>vqs[i].vq.mutex);
- n->vqs[i].vq.acked_backend_features = features;
- mutex_unlock(>vqs[i].vq.mutex);
- }
- mutex_unlock(>dev.mutex);
-
- return 0;
-}
-
static int vhost_net_set_features(struct vhost_net *n, u64 features)
{
size_t vhost_hlen, sock_hlen, hdr_len;
@@ -1737,7 +1722,8 @@ static long vhost_net_ioctl(struct file *f, unsigned int
ioctl,
return -EFAULT;
if (features & ~VHOST_NET_BACKEND_FEATURES)
return -EOPNOTSUPP;
- return vhost_net_set_backend_features(n, features);
+ vhost_set_backend_features(>dev, features);
+ return 0;
case VHOST_RESET_OWNER:
return vhost_net_reset_owner(n);
case VHOST_SET_OWNER:
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index dc510dc2b1ef..ba61f499d420 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2700,6 +2700,21 @@ struct vhost_msg_node *vhost_dequeue_msg(struct
vhost_dev *dev,
}
EXPORT_SYMBOL_GPL(vhost_dequeue_msg);
+void vhost_set_backend_features(struct vhost_dev *dev, u64 features)
+{
+ struct vhost_virtqueue *vq;
+ int i;
+
+ mutex_lock(>mutex);
+ for (i = 0; i < dev->nvqs; ++i) {
+ vq = dev->vqs[i];
+ mutex_lock(>mutex);
+ vq->acked_backend_features = features;
+ mutex_unlock(>mutex);
+ }
+ mutex_unlock(>mutex);
+}
+EXPORT_SYMBOL_GPL(vhost_set_backend_features);
static int __init vhost_init(void)
{
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 264a2a2fae97..52753aecd82a 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -223,6 +223,8 @@ void vhost_enqueue_msg(struct vhost_dev *dev,
struct vhost_msg_node *node);
struct vhost_msg_node *vhost_dequeue_msg(struct vhost_dev *dev,
struct list_head *head);
+void vhost_set_backend_features(struct vhost_dev *dev, u64 features);
+
__poll_t vhost_chr_poll(struct file *file, struct vhost_dev *dev,
poll_table *wait);
ssize_t vhost_chr_read_iter(struct vhost_dev *dev, struct iov_iter *to,
--
2.20.1
[PATCH RFC 1/5] vhost-vdpa: refine ioctl pre-processing
Switch to use 'switch' to make the codes more easier to be extended.
Signed-off-by: Jason Wang
---
drivers/vhost/vdpa.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 77a0c9fb6cc3..db4c9cb44c61 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -353,15 +353,16 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v,
unsigned int cmd,
idx = array_index_nospec(idx, v->nvqs);
vq = >vqs[idx];
- if (cmd == VHOST_VDPA_SET_VRING_ENABLE) {
+ switch (cmd) {
+ case VHOST_VDPA_SET_VRING_ENABLE:
if (copy_from_user(, argp, sizeof(s)))
return -EFAULT;
ops->set_vq_ready(vdpa, idx, s.num);
return 0;
- }
-
- if (cmd == VHOST_GET_VRING_BASE)
+ case VHOST_GET_VRING_BASE:
vq->last_avail_idx = ops->get_vq_state(v->vdpa, idx);
+ break;
+ }
r = vhost_vring_ioctl(>vdev, cmd, argp);
if (r)
--
2.20.1
[PATCH RFC 0/5] support batched IOTLB updating in vhost-vdpa
Hi all: This series tries to support batched IOTLB updating vhost-vdpa. Currently vhost-vdpa accepts userspace mapping via IOTLB API, and it can only forward one mapping to IOMMU or device through IOMMU API or dma_map(). Though set_map() is deisgend to have the capability to pass an rbtree based mapping to vDPA device, it's still be called at least once for each VHOST_IOTLB_UPDATE or VHOST_IOTLB_INVALIDATE. This is because vhost-vdpa doesn't know the userspace start or stop then updating. So this patch introduces two flags as hints for vhost-vdpa to call set_map() only when userspace finish a batch of IOTLB updating. So instead of: 1) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s) 2) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s) ... n) VHOST_IOTLB_UPDATE/VHOST_IOTLB_INVALIDATE -> set_map() (s) With the help of hints, we do: 0) VHOST_IOTLB_BATCH_START 1) VHOST_IOTLB_UPDATE/INVALIDATE ... n) VHOST_IOTLB_UPDATE/INVALIDATE n+1) VHOST_IOTLB_BATCH_END -> set_map() One one call of set_map() to vDPA device for a batch of IOTLB mappings. So for the device that has its own DMA translation logic, it can efficiently structure the memory mapping to get best performance. Note, this only impact the devices that want its own DMA translation. For other type of device, no changes in behaviour. Please reivew. Jason Wang (5): vhost-vdpa: refine ioctl pre-processing vhost: generialize backend features setting/getting vhost-vdpa: support get/set backend features vhost-vdpa: support IOTLB batching hints vdpasim: support batch updating drivers/vdpa/vdpa_sim/vdpa_sim.c | 40 +-- drivers/vhost/net.c | 18 ++- drivers/vhost/vdpa.c | 55 ++-- drivers/vhost/vhost.c| 15 + drivers/vhost/vhost.h| 2 ++ include/uapi/linux/vhost.h | 2 ++ include/uapi/linux/vhost_types.h | 7 7 files changed, 110 insertions(+), 29 deletions(-) -- 2.20.1
Re: + scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist.patch added to -mm tree
On Wed, 2020-06-17 at 14:32 -0700, a...@linux-foundation.org wrote: > The patch titled > Subject: scripts/deprecated_terms: recommend denylist/allowlist instead > of blacklist/whitelist > has been added to the -mm tree. Its filename is > > scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist.patch [] > -- > From: SeongJae Park > Subject: scripts/deprecated_terms: recommend denylist/allowlist instead of > blacklist/whitelist > > This commit recommends that patches replace 'blacklist' and 'whitelist' > with 'denylist' and 'allowlist', because the new suggestions are > incontrovertible, doesn't make people hurt, and are more self-explanatory. [] > --- > a/scripts/deprecated_terms.txt~scripts-deprecated_terms-recommend-denylist-allowlist-instead-of-blacklist-whitelist > +++ a/scripts/deprecated_terms.txt > @@ -3,3 +3,5 @@ > # The format of each line is: > # deprecated||suggested > # > +blacklist||denylist > +whitelist||allowlist I think this is a poor use of deprecated terms as it has nothing to do with skin color.
Re: [PATCH v5 3/7] fs: Add fd_install_received() wrapper for __fd_install_received()
On Wed, Jun 17, 2020 at 03:03:23PM -0700, Kees Cook wrote:
> For both pidfd and seccomp, the __user pointer is not used. Update
> __fd_install_received() to make writing to ufd optional via a NULL check.
> However, for the fd_install_received_user() wrapper, ufd is NULL checked
> so an -EFAULT can be returned to avoid changing the SCM_RIGHTS interface
> behavior. Add new wrapper fd_install_received() for pidfd and seccomp
> that does not use the ufd argument. For the new helper, the new fd needs
> to be returned on success. Update the existing callers to handle it.
>
> Signed-off-by: Kees Cook
> ---
> fs/file.c| 22 ++
> include/linux/file.h | 7 +++
> net/compat.c | 2 +-
> net/core/scm.c | 2 +-
> 4 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/fs/file.c b/fs/file.c
> index f2167d6feec6..de85a42defe2 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -942,9 +942,10 @@ int replace_fd(unsigned fd, struct file *file, unsigned
> flags)
> * @o_flags: the O_* flags to apply to the new fd entry
> *
> * Installs a received file into the file descriptor table, with appropriate
> - * checks and count updates. Writes the fd number to userspace.
> + * checks and count updates. Optionally writes the fd number to userspace, if
> + * @ufd is non-NULL.
> *
> - * Returns -ve on error.
> + * Returns newly install fd or -ve on error.
> */
> int __fd_install_received(struct file *file, int __user *ufd, unsigned int
> o_flags)
> {
> @@ -960,20 +961,25 @@ int __fd_install_received(struct file *file, int __user
> *ufd, unsigned int o_fla
> if (new_fd < 0)
> return new_fd;
>
> - error = put_user(new_fd, ufd);
> - if (error) {
> - put_unused_fd(new_fd);
> - return error;
> + if (ufd) {
> + error = put_user(new_fd, ufd);
> + if (error) {
> + put_unused_fd(new_fd);
> + return error;
> + }
> }
>
> - /* Bump the usage count and install the file. */
> + /* Bump the usage count and install the file. The resulting value of
> + * "error" is ignored here since we only need to take action when
> + * the file is a socket and testing "sock" for NULL is sufficient.
> + */
> sock = sock_from_file(file, );
> if (sock) {
> sock_update_netprioidx(>sk->sk_cgrp_data);
> sock_update_classid(>sk->sk_cgrp_data);
> }
> fd_install(new_fd, get_file(file));
> - return 0;
> + return new_fd;
> }
>
> static int ksys_dup3(unsigned int oldfd, unsigned int newfd, int flags)
> diff --git a/include/linux/file.h b/include/linux/file.h
> index fe18a1a0d555..e19974ed9322 100644
> --- a/include/linux/file.h
> +++ b/include/linux/file.h
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> struct file;
>
> @@ -96,8 +97,14 @@ extern int __fd_install_received(struct file *file, int
> __user *ufd,
> static inline int fd_install_received_user(struct file *file, int __user
> *ufd,
> unsigned int o_flags)
> {
> + if (ufd == NULL)
> + return -EFAULT;
Isn't this *technically* a behvaiour change? Nonetheless, I think this is a
much better
approach than forcing everyone to do null checking, and avoids at least one
error case
where the kernel installs FDs for SCM_RIGHTS, and they're not actualy usable.
> return __fd_install_received(file, ufd, o_flags);
> }
> +static inline int fd_install_received(struct file *file, unsigned int
> o_flags)
> +{
> + return __fd_install_received(file, NULL, o_flags);
> +}
>
> extern void flush_delayed_fput(void);
> extern void __fput_sync(struct file *);
> diff --git a/net/compat.c b/net/compat.c
> index 94f288e8dac5..71494337cca7 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -299,7 +299,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
> scm_cookie *scm)
>
> for (i = 0; i < fdmax; i++) {
> err = fd_install_received_user(scm->fp->fp[i], cmsg_data + i,
> o_flags);
> - if (err)
> + if (err < 0)
> break;
> }
>
> diff --git a/net/core/scm.c b/net/core/scm.c
> index df190f1fdd28..b9a0442ebd26 100644
> --- a/net/core/scm.c
> +++ b/net/core/scm.c
> @@ -307,7 +307,7 @@ void scm_detach_fds(struct msghdr *msg, struct scm_cookie
> *scm)
>
> for (i = 0; i < fdmax; i++) {
> err = fd_install_received_user(scm->fp->fp[i], cmsg_data + i,
> o_flags);
> - if (err)
> + if (err < 0)
> break;
> }
>
> --
> 2.25.1
>
Reviewed-by: Sargun Dhillon
Re: [PATCH 4/5] dt-bindings: fpga: xilinx-slave-serial: add optional INIT_B GPIO
Hi Rob, Moritz, On 18/06/20 00:39, Rob Herring wrote: > On Thu, Jun 11, 2020 at 11:11:43PM +0200, Luca Ceresoli wrote: >> The INIT_B is used by the 6 and 7 series to report the programming status, >> providing more control and information about programming errors. >> >> Signed-off-by: Luca Ceresoli >> --- >> .../devicetree/bindings/fpga/xilinx-slave-serial.txt | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt >> b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt >> index 9f103f3872e8..a049082e1513 100644 >> --- a/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt >> +++ b/Documentation/devicetree/bindings/fpga/xilinx-slave-serial.txt >> @@ -16,6 +16,10 @@ Required properties: >> - prog_b-gpios: config pin (referred to as PROGRAM_B in the manual) >> - done-gpios: config status pin (referred to as DONE in the manual) >> >> +Optional properties: >> +- init_b-gpios: initialization status and configuration error pin >> +(referred to as INIT_B in the manual) > > Don't use '_' in property names: > > init-b-gpios OK, will fix. Moritz, please don't apply this version of patches 4 and 5 if you still haven't done so. Now what about the existing prog_b-gpios property? Should we just leave it as is for backward compatibility, or is there a migration path to fix it as well? Thanks. -- Luca
Re: [PATCH v3] seccomp: Add find_notification helper
On Wed, Jun 17, 2020 at 01:08:44PM -0700, Nathan Chancellor wrote:
> On Mon, Jun 01, 2020 at 04:25:32AM -0700, Sargun Dhillon wrote:
> > This adds a helper which can iterate through a seccomp_filter to
> > find a notification matching an ID. It removes several replicated
> > chunks of code.
> >
> > Signed-off-by: Sargun Dhillon
> > Acked-by: Christian Brauner
> > Reviewed-by: Tycho Andersen
> > Cc: Matt Denton
> > Cc: Kees Cook ,
> > Cc: Jann Horn ,
> > Cc: Robert Sesek ,
> > Cc: Chris Palmer
> > Cc: Christian Brauner
> > Cc: Tycho Andersen
> > ---
> > kernel/seccomp.c | 55
> > 1 file changed, 28 insertions(+), 27 deletions(-)
> >
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 55a6184f5990..cc6b47173a95 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -41,6 +41,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > enum notify_state {
> > SECCOMP_NOTIFY_INIT,
> > @@ -1021,10 +1022,27 @@ static int seccomp_notify_release(struct inode
> > *inode, struct file *file)
> > return 0;
> > }
> >
> > +/* must be called with notif_lock held */
> > +static inline struct seccomp_knotif *
> > +find_notification(struct seccomp_filter *filter, u64 id)
> > +{
> > + struct seccomp_knotif *cur;
> > +
> > + lockdep_assert_held(>notify_lock);
> > +
> > + list_for_each_entry(cur, >notif->notifications, list) {
> > + if (cur->id == id)
> > + return cur;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +
> > static long seccomp_notify_recv(struct seccomp_filter *filter,
> > void __user *buf)
> > {
> > - struct seccomp_knotif *knotif = NULL, *cur;
> > + struct seccomp_knotif *knotif, *cur;
> > struct seccomp_notif unotif;
> > ssize_t ret;
> >
> > @@ -1078,15 +1096,8 @@ static long seccomp_notify_recv(struct
> > seccomp_filter *filter,
> > * may have died when we released the lock, so we need to make
> > * sure it's still around.
> > */
> > - knotif = NULL;
> > mutex_lock(>notify_lock);
> > - list_for_each_entry(cur, >notif->notifications, list) {
> > - if (cur->id == unotif.id) {
> > - knotif = cur;
> > - break;
> > - }
> > - }
> > -
> > + knotif = find_notification(filter, unotif.id);
> > if (knotif) {
> > knotif->state = SECCOMP_NOTIFY_INIT;
> > up(>notif->request);
> > @@ -1101,7 +1112,7 @@ static long seccomp_notify_send(struct seccomp_filter
> > *filter,
> > void __user *buf)
> > {
> > struct seccomp_notif_resp resp = {};
> > - struct seccomp_knotif *knotif = NULL, *cur;
> > + struct seccomp_knotif *knotif;
> > long ret;
> >
> > if (copy_from_user(, buf, sizeof(resp)))
> > @@ -1118,13 +1129,7 @@ static long seccomp_notify_send(struct
> > seccomp_filter *filter,
> > if (ret < 0)
> > return ret;
> >
> > - list_for_each_entry(cur, >notif->notifications, list) {
> > - if (cur->id == resp.id) {
> > - knotif = cur;
> > - break;
> > - }
> > - }
> > -
> > + knotif = find_notification(filter, resp.id);
> > if (!knotif) {
> > ret = -ENOENT;
> > goto out;
> > @@ -1150,7 +1155,7 @@ static long seccomp_notify_send(struct seccomp_filter
> > *filter,
> > static long seccomp_notify_id_valid(struct seccomp_filter *filter,
> > void __user *buf)
> > {
> > - struct seccomp_knotif *knotif = NULL;
>
> I don't know that this should have been removed, clang now warns:
>
> kernel/seccomp.c:1063:2: warning: variable 'knotif' is used uninitialized
> whenever 'for' loop exits because its condition is false
> [-Wsometimes-uninitialized]
> list_for_each_entry(cur, >notif->notifications, list) {
> ^
> include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
> >member != (head);\
> ^~
> kernel/seccomp.c:1075:7: note: uninitialized use occurs here
> if (!knotif) {
> ^~
> kernel/seccomp.c:1063:2: note: remove the condition if it is always true
> list_for_each_entry(cur, >notif->notifications, list) {
> ^
> include/linux/list.h:602:7: note: expanded from macro 'list_for_each_entry'
> >member != (head);\
> ^
> kernel/seccomp.c:1045:31: note: initialize the variable 'knotif' to silence
> this warning
> struct seccomp_knotif *knotif, *cur;
> ^
> = NULL
> 1 warning generated.
>
Re: [PATCH v3] libata: Use per port sync for detach
Hi Jens,
> On Jun 3, 2020, at 16:40, John Garry wrote:
>
> On 03/06/2020 08:48, Kai-Heng Feng wrote:
>> Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before
>> detach") may cause system freeze during suspend.
>> Using async_synchronize_full() in PM callbacks is wrong, since async
>> callbacks that are already scheduled may wait for not-yet-scheduled
>> callbacks, causes a circular dependency.
>> Instead of using big hammer like async_synchronize_full(), use async
>> cookie to make sure port probe are synced, without affecting other
>> scheduled PM callbacks.
>> Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before
>> detach")
>> BugLink: https://bugs.launchpad.net/bugs/1867983
>> Suggested-by: John Garry
>> Signed-off-by: Kai-Heng Feng
>
> thanks,
> Tested-by: John Garry
Can you please review or merge this patch?
Kai-Heng
>
>> ---
>> v3:
>> - Move the comment to properly align with the code.
>> v2:
>> - Sync up to cookie + 1.
>> - Squash the synchronization into the same loop.
>> drivers/ata/libata-core.c | 11 +--
>> include/linux/libata.h| 3 +++
>> 2 files changed, 8 insertions(+), 6 deletions(-)
>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
>> index 69361ec43db5..b1cd4d97bc2a 100644
>> --- a/drivers/ata/libata-core.c
>> +++ b/drivers/ata/libata-core.c
>> @@ -42,7 +42,6 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>> #include
>> @@ -5778,7 +5777,7 @@ int ata_host_register(struct ata_host *host, struct
>> scsi_host_template *sht)
>> /* perform each probe asynchronously */
>> for (i = 0; i < host->n_ports; i++) {
>> struct ata_port *ap = host->ports[i];
>> -async_schedule(async_port_probe, ap);
>> +ap->cookie = async_schedule(async_port_probe, ap);
>> }
>> return 0;
>> @@ -5920,11 +5919,11 @@ void ata_host_detach(struct ata_host *host)
>> {
>> int i;
>> - /* Ensure ata_port probe has completed */
>> -async_synchronize_full();
>> -
>> -for (i = 0; i < host->n_ports; i++)
>> +for (i = 0; i < host->n_ports; i++) {
>> +/* Ensure ata_port probe has completed */
>> +async_synchronize_cookie(host->ports[i]->cookie + 1);
>> ata_port_detach(host->ports[i]);
>> +}
>> /* the host is dead now, dissociate ACPI */
>> ata_acpi_dissociate(host);
>> diff --git a/include/linux/libata.h b/include/linux/libata.h
>> index af832852e620..8a4843704d28 100644
>> --- a/include/linux/libata.h
>> +++ b/include/linux/libata.h
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>>/*
>> * Define if arch has non-standard setup. This is a _PCI_ standard
>> @@ -872,6 +873,8 @@ struct ata_port {
>> struct timer_list fastdrain_timer;
>> unsigned long fastdrain_cnt;
>> + async_cookie_t cookie;
>> +
>> int em_message_type;
>> void*private_data;
>>
>
Re: [PATCH][next] bcache: Use struct_size() in kzalloc()
On Thu, 2020-06-18 at 13:38 +0800, Coly Li wrote: > On 2020/6/18 06:27, Gustavo A. R. Silva wrote: > > Make use of the struct_size() helper instead of an open-coded version > > in order to avoid any potential type mistakes. [] > > diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c [] > > - io = kzalloc(sizeof(struct dirty_io) + > > -sizeof(struct bio_vec) * > > -DIV_ROUND_UP(KEY_SIZE(>key), > > - PAGE_SECTORS), > > + io = kzalloc(struct_size(io, bio.bi_inline_vecs, > ^^ > I like this :-) > > > + DIV_ROUND_UP(KEY_SIZE(>key), > > PAGE_SECTORS)), > > The above line seems too long for 80 characters limitation. Does > checkpatch.pl complain for this ? No. checkpatch has changed: >From bdc48fa11e46f867ea4d75fa59ee87a7f48be144 Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Fri, 29 May 2020 16:12:21 -0700 Subject: [PATCH] checkpatch/coding-style: deprecate 80-column warning Yes, staying withing 80 columns is certainly still _preferred_. But it's not the hard limit that the checkpatch warnings imply, and other concerns can most certainly dominate. Increase the default limit to 100 characters. Not because 100 characters is some hard limit either, but that's certainly a "what are you doing" kind of value and less likely to be about the occasional slightly longer lines. Miscellanea: - to avoid unnecessary whitespace changes in files, checkpatch will no longer emit a warning about line length when scanning files unless --strict is also used - Add a bit to coding-style about alignment to open parenthesis Signed-off-by: Joe Perches Signed-off-by: Linus Torvalds >
drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in argument 1 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1b5044021070efa3259f3e9548dc35d1eb6aa844 commit: 80591e61a0f7e88deaada69844e4a31280c4a38f kbuild: tell sparse about the $ARCH date: 7 months ago config: s390-randconfig-s032-20200618 (attached as .config) compiler: s390-linux-gcc (GCC) 9.3.0 reproduce: # apt-get install sparse # sparse version: v0.6.2-rc1-10-gc17b1b06-dirty git checkout 80591e61a0f7e88deaada69844e4a31280c4a38f # save the attached .config to linux build tree make W=1 C=1 ARCH=s390 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot sparse warnings: (new ones prefixed by >>) >> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void *s @@ got >> unsigned char [noderef] [usertype] *cursorbase @@ >> drivers/video/fbdev/tdfxfb.c:1120:27: sparse: expected void *s drivers/video/fbdev/tdfxfb.c:1120:27: sparse: got unsigned char [noderef] [usertype] *cursorbase drivers/video/fbdev/tdfxfb.c:1131:33: sparse: sparse: cast removes address space '' of expression drivers/video/fbdev/tdfxfb.c:1134:33: sparse: sparse: cast removes address space '' of expression include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:179:15: sparse: sparse: cast to restricted __le32 include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype] include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 1 (different base types) @@ expected unsigned int [usertype] val @@ got restricted __le32 [usertype] @@ include/asm-generic/io.h:225:22: sparse: expected unsigned int [usertype] val include/asm-generic/io.h:225:22: sparse:
Re: [PATCH][next] bcache: Use struct_size() in kzalloc()
On 2020/6/18 06:27, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes.
>
> This code was detected with the help of Coccinelle and, audited and
> fixed manually.
>
> Signed-off-by: Gustavo A. R. Silva ---
> drivers/md/bcache/writeback.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
> index 1cf1e5016cb9..c0db3c860179 100644
> --- a/drivers/md/bcache/writeback.c
> +++ b/drivers/md/bcache/writeback.c
> @@ -459,10 +459,8 @@ static void read_dirty(struct cached_dev *dc)
> for (i = 0; i < nk; i++) {
> w = keys[i];
>
> - io = kzalloc(sizeof(struct dirty_io) +
> - sizeof(struct bio_vec) *
> - DIV_ROUND_UP(KEY_SIZE(>key),
> - PAGE_SECTORS),
> + io = kzalloc(struct_size(io, bio.bi_inline_vecs,
^^
I like this :-)
> + DIV_ROUND_UP(KEY_SIZE(>key),
> PAGE_SECTORS)),
The above line seems too long for 80 characters limitation. Does
checkpatch.pl complain for this ?
Thanks.
Coly Li
>GFP_KERNEL);
> if (!io)
> goto err;
>
Re: linux-next: Tree for Jun 18 (fs/io_uring)
On 6/17/20 9:15 PM, Stephen Rothwell wrote:
> Hi all,
>
> News: there will be no linux-next release tomorrow.
>
> Changes since 20200617:
>
when CONFIG_BLOCK is not set/enabled:
../fs/io_uring.c: In function 'io_async_task_func':
../fs/io_uring.c:4559:7: error: implicit declaration of function
'io_sq_thread_acquire_mm'; did you mean 'atomic_read_acquire'?
[-Werror=implicit-function-declaration]
if (io_sq_thread_acquire_mm(ctx, req)) {
^~~
atomic_read_acquire
../fs/io_uring.c: In function 'io_sq_thread':
../fs/io_uring.c:6268:4: error: implicit declaration of function
'io_sq_thread_drop_mm'; did you mean 'io_sq_thread'?
[-Werror=implicit-function-declaration]
io_sq_thread_drop_mm(ctx);
^~~~
io_sq_thread
--
~Randy
Reported-by: Randy Dunlap
Re: [PATCH v2 0/8] Introduce sv48 support
Hi Palmer, Le 6/3/20 à 4:10 AM, Alexandre Ghiti a écrit : This patchset implements sv48 support at runtime. The kernel will try to boot with 4-level page table and will fallback to 3-level if the HW does not support it. The biggest advantage is that we only have one kernel for 64bit, which is way easier to maintain. Folding the 4th level into a 3-level page table has almost no cost at runtime. But as mentioned Palmer, the relocatable code generated is less performant. At the moment, there is no way to build a 3-level page table non-relocatable 64bit kernel. We agreed that distributions will use this runtime configuration anyway, but Palmer proposed to introduce a new Kconfig, which I will do later as sv48 support was asked for 5.8. Finally, the user can now ask for sv39 explicitly by using the device-tree which will reduce memory footprint and reduce the number of memory accesses in case of TLB miss. Changes in v2: * Move variable declarations to pgtable.h in patch 5/7 as suggested by Anup * Restore mmu-type properties in patch 6 as suggested by Anup * Fix unused variable in patch 5 that was used in patch 6 * Fix SPARSEMEM build (patch 2 was modified so I dropped the Reviewed-by) * Applied various Reviewed-by Alexandre Ghiti (8): riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE riscv: Allow to dynamically define VA_BITS riscv: Simplify MAXPHYSMEM config riscv: Prepare ptdump for vm layout dynamic addresses riscv: Implement sv48 support riscv: Allow user to downgrade to sv39 when hw supports sv48 riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo riscv: Explicit comment about user virtual address space size arch/riscv/Kconfig | 34 ++--- arch/riscv/include/asm/csr.h| 3 +- arch/riscv/include/asm/fixmap.h | 1 + arch/riscv/include/asm/page.h | 15 +++ arch/riscv/include/asm/pgalloc.h| 36 ++ arch/riscv/include/asm/pgtable-64.h | 97 +- arch/riscv/include/asm/pgtable.h| 31 - arch/riscv/include/asm/sparsemem.h | 6 +- arch/riscv/kernel/cpu.c | 23 ++-- arch/riscv/kernel/head.S| 3 +- arch/riscv/mm/context.c | 2 +- arch/riscv/mm/init.c| 194 arch/riscv/mm/ptdump.c | 49 +-- 13 files changed, 412 insertions(+), 82 deletions(-) Do you any remark regarding this patchset and the others ? Thanks, Alex
[PATCH v3 3/3] media: v4l: xilinx: Add Xilinx UHD-SDI Rx Subsystem driver
The Xilinx UHD-SDI Rx subsystem soft IP is used to capture native SDI streams from SDI sources like SDI broadcast equipment like cameras and mixers. This block outputs either native SDI, native video or AXI4-Stream compliant data stream for further processing. Please refer to PG290 for details. The driver is used to configure the IP to add framer, search for specific modes, get the detected mode, stream parameters, errors, etc. It also generates events for video lock/unlock, bridge over/under flow. The driver supports 10/12 bpc YUV 422 media bus format currently. It also decodes the stream parameters based on the ST352 packet embedded in the stream. In case the ST352 packet isn't present in the stream, the core's detected properties are used to set stream properties. The driver currently supports only the AXI4-Stream IP configuration. Signed-off-by: Vishal Sagar --- v3 - fixed KConfig with better description - removed unnecessary header files - converted uppercase to lowercase for all hex values - merged core struct to state struct - removed most one line functions and replaced with direct reg read/write or macros - dt property bpp to bpc. default 10. not mandatory. - fixed subscribe events, log_status, s_stream - merged overflow/underflow to one event - moved all controls to xilinx-sdirxss.h - max events from 128 to 8 - used FIELD_GET() instead of custom macro - updated the controls documentation - added spinlock - removed 3GB control and added mode to detect bitmask - fixed format for (width, height, colorspace, xfer func, etc) - added dv_timings_cap, s/g_dv_timings - fixed set/get_format - fix v4l control registrations - fix order of registration / deregistration in probe() remove() - fixed other comments from Hyun, Laurent and Hans - things yet to close - adding source port for connector (Laurent's suggestion) - adding new FIELD type for Transport Stream V4L2_FIELD_ALTERNATE_PROG (Han's suggestion) - Update / remove EDH or CRC related controls v2 - Added DV timing support based on Hans Verkuilś feedback - More documentation to custom v4l controls and events - Fixed Hyunś comments - Added macro for masking and shifting as per Joe Perches comments - Updated to latest as per Xilinx github repo driver like adding new DV timings not in mainline yet uptill 03/21/20 drivers/media/platform/xilinx/Kconfig | 11 + drivers/media/platform/xilinx/Makefile|1 + .../media/platform/xilinx/xilinx-sdirxss.c| 2121 + include/uapi/linux/v4l2-controls.h|6 + include/uapi/linux/xilinx-sdirxss.h | 283 +++ 5 files changed, 2422 insertions(+) create mode 100644 drivers/media/platform/xilinx/xilinx-sdirxss.c create mode 100644 include/uapi/linux/xilinx-sdirxss.h diff --git a/drivers/media/platform/xilinx/Kconfig b/drivers/media/platform/xilinx/Kconfig index 01c96fb66414..578cdcc1036e 100644 --- a/drivers/media/platform/xilinx/Kconfig +++ b/drivers/media/platform/xilinx/Kconfig @@ -12,6 +12,17 @@ config VIDEO_XILINX if VIDEO_XILINX +config VIDEO_XILINX_SDIRXSS + tristate "Xilinx UHD SDI Rx Subsystem" + help + Driver for Xilinx UHD-SDI Rx Subsystem. This is a V4L sub-device + based driver that takes input from a SDI source like SDI camera and + converts it into an AXI4-Stream. The subsystem comprises a SMPTE + UHD-SDI Rx core, a SDI Rx to Native Video bridge and a Video In to + AXI4-Stream bridge. The driver is used to set different stream + detection modes and identify stream properties to properly configure + downstream. + config VIDEO_XILINX_TPG tristate "Xilinx Video Test Pattern Generator" depends on VIDEO_XILINX diff --git a/drivers/media/platform/xilinx/Makefile b/drivers/media/platform/xilinx/Makefile index 4cdc0b1ec7a5..3beaf24d832c 100644 --- a/drivers/media/platform/xilinx/Makefile +++ b/drivers/media/platform/xilinx/Makefile @@ -3,5 +3,6 @@ xilinx-video-objs += xilinx-dma.o xilinx-vip.o xilinx-vipp.o obj-$(CONFIG_VIDEO_XILINX) += xilinx-video.o +obj-$(CONFIG_VIDEO_XILINX_SDIRXSS) += xilinx-sdirxss.o obj-$(CONFIG_VIDEO_XILINX_TPG) += xilinx-tpg.o obj-$(CONFIG_VIDEO_XILINX_VTC) += xilinx-vtc.o diff --git a/drivers/media/platform/xilinx/xilinx-sdirxss.c b/drivers/media/platform/xilinx/xilinx-sdirxss.c new file mode 100644 index ..e39aab7c656a --- /dev/null +++ b/drivers/media/platform/xilinx/xilinx-sdirxss.c @@ -0,0 +1,2121 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Driver for Xilinx SDI Rx Subsystem + * + * Copyright (C) 2017 - 2020 Xilinx, Inc. + * + * Contacts: Vishal Sagar + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* + * SDI Rx register map, bitmask and offsets + */ +#define XSDIRX_RST_CTRL_REG0x00 +#define XSDIRX_MDL_CTRL_REG0x04 +#define XSDIRX_GLBL_IER_REG0x0c +#define
[PATCH v3 0/3] Add support for Xilinx UHD-SDI Receiver subsystem
Xilinx SMPTE UHD-SDI Receiver Subsystem The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create systems based on SMPTE SDI protocols. It receives unaligned native SDI streams from the SDI GT PHY and outputs an AXI4-Stream video stream, native video, or native SDI using Xilinx transceivers as the physical layer. SMPTE UHD-SDI Rx Subsystem AXI4-Stream Architecture ++ | Native SDI Native Video| SDI | +=+ | ++ | +=+|AXI4 Stream| | SMPTE | V | SDI Rx | V | Video In||Stream ->|-->| UHD-SDI |-->|to |->| to|--->|---> | | RX| | Native| | AXI4-Stream || | +=+ |Video Bridge| +=+| | | ^ ++ | <--|--+ | | sdi_rx_irq| | | +=+===+==+ |^ ^ || | s_axi_aclk sdi_rx_clk video_out_clk The subsystem consists of the following subcores: - SMPTE UHD-SDI (RX) - SDI RX to Video Bridge - Video In to AXI4-Stream At design time, this subsystem can be configured in 3Gbps, 6Gbps or 12Gbps mode. It can also be configured to output - SDI Native stream - Native Video - AXI4-Stream This driver only supports the AXI4-Stream configuration as there is a corresponding media bus format for YUV 422 10/12 bits per component. Though the core also supports RBG/YUV444/YUV420 10/12 bits per component, these are not supported in driver due to lack of corresponding media bus format currently. The SDI core has detection modes where in it can be configured to detect one or more modes from SD (Standard Definition), HD (High Definition), 3GA, 3GB, 6G and 12G modes. When the core has detected the format, it generates a video lock. In case the source is removed or there is data corruption, the video may unlock. This is intimated to the application via a V4L2 event. Other events which application can subscribe are for overflow and underflow of the video bridges. The driver gives out the stream properties like width, height, colorformat, frame interval and progressive/interlaced based on the ST352 packet in SDI stream. If the ST352 packet is absent, then the values detected by the SMPTE UHD-SDI Rx core are used. The SDI core detection modes and detected mode, errors, etc are all accessible via v4l controls. This driver has been tested with Omnitek Ultra4K HD, Phabrix Qx and Blackmagic SDI-HDMI convertors. v2 1/2 - Converted to yaml format - Removed references to xlnx,video* - Fixed as per Sakari Ailus and Rob Herring's comments 2/2 - Added DV timing support based on Hans Verkuilś feedback - More documentation to custom v4l controls and events - Fixed Hyunś comments - Added macro for masking and shifting as per Joe Perches comments - Updated to latest as per Xilinx github repo driver like adding new DV timings not in mainline yet uptill 03/21/20 Vishal Sagar (3): v4l2-dv-timings: Add timings for 1920x1080P48 and 4KP48 media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem media: v4l: xilinx: Add Xilinx UHD-SDI Rx Subsystem driver .../bindings/media/xilinx/xlnx,sdirxss.yaml | 132 + drivers/media/platform/xilinx/Kconfig | 11 + drivers/media/platform/xilinx/Makefile|1 + .../media/platform/xilinx/xilinx-sdirxss.c| 2121 + include/dt-bindings/media/xilinx-sdi.h| 20 + include/uapi/linux/v4l2-controls.h|6 + include/uapi/linux/v4l2-dv-timings.h | 31 +- include/uapi/linux/xilinx-sdirxss.h | 283 +++ 8 files changed, 2604 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml create mode 100644 drivers/media/platform/xilinx/xilinx-sdirxss.c create mode 100644 include/dt-bindings/media/xilinx-sdi.h create mode 100644 include/uapi/linux/xilinx-sdirxss.h -- 2.21.0
[PATCH v3 2/3] media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem
Add bindings documentation for Xilinx UHD-SDI Receiver Subsystem.
The Xilinx UHD-SDI Receiver Subsystem consists of SMPTE UHD-SDI (RX) IP
core, an SDI RX to Video Bridge IP core to convert SDI video to native
video and a Video In to AXI4-Stream IP core to convert native video to
AXI4-Stream.
Signed-off-by: Vishal Sagar
---
v3
- bpc instead of bpp
- removed bpc as required property (default to 10 bpc)
- add dt-bindings/media/xilinx-sdi.h
- made line-rate as u32 instead of string
- fixed reg
- fixed s/upto/up to/
v2
- Removed references to xlnx,video*
- Fixed as per Sakari Ailus and Rob Herring's comments
- Converted to yaml format
.../bindings/media/xilinx/xlnx,sdirxss.yaml | 132 ++
include/dt-bindings/media/xilinx-sdi.h| 20 +++
2 files changed, 152 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
create mode 100644 include/dt-bindings/media/xilinx-sdi.h
diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
new file mode 100644
index ..6cfc18ca435f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/xilinx/xlnx,sdirxss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+
+title: Xilinx SMPTE UHD-SDI Receiver Subsystem
+
+maintainers:
+ - Vishal Sagar
+
+description: |
+ The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create
systems
+ based on SMPTE SDI protocols. It receives unaligned native SDI streams from
+ the SDI GT PHY and outputs an AXI4-Stream video stream, native video, or
+ native SDI using Xilinx transceivers as the physical layer.
+
+ The subsystem consists of
+ 1 - SMPTE UHD-SDI Rx
+ 2 - SDI Rx to Native Video Bridge
+ 3 - Video In to AXI4-Stream Bridge
+
+ The subsystem can capture SDI streams in up to 12G mode 8 data streams and
output
+ a dual pixel per clock RGB/YUV444,422/420 10/12 bits per component
AXI4-Stream.
+
+properties:
+ compatible:
+items:
+ - enum:
+- xlnx,v-smpte-uhdsdi-rx-ss-2.0
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+description: List of clock specifiers
+items:
+ - description: AXI4-Lite clock
+ - description: SMPTE UHD-SDI Rx core clock
+ - description: Video clock
+
+ clock-names:
+items:
+ - const: s_axi_aclk
+ - const: sdi_rx_clk
+ - const: video_out_clk
+
+ xlnx,bpc:
+description: Bits per component supported. Can be 10 or 12 bits per
component only.
+allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum: [10, 12]
+
+ xlnx,line-rate:
+description: |
+ The maximum mode supported by the design. Possible values are as below
+ 0 - XSDI_STD_3G - 3G mode
+ 1 - XSDI_STD_6G - 6G mode
+ 2 - XSDI_STD_12G_8DS - 12G mode with 8 data streams
+allOf:
+ - $ref: "/schemas/types.yaml#/definitions/uint32"
+ - enum: [0, 1, 2]
+
+ xlnx,include-edh:
+type: boolean
+description: |
+ This is present when the Error Detection and Handling processor is
+ enabled in design.
+
+ ports:
+type: object
+description: |
+ Generally the SDI port is connected to a device like SDI Broadcast camera
+ which is independently controlled. Hence port@0 is a source port which
can be
+ connected to downstream IP which can work with AXI4 Stream data.
+properties:
+ port@0:
+type: object
+description: Source port
+properties:
+ reg:
+const: 0
+ endpoint:
+type: object
+properties:
+ remote-endpoint: true
+required:
+ - remote-endpoint
+additionalProperties: false
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - xlnx,line-rate
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+uhdsdirxss: v-smpte-uhdsdi-rxss@8000 {
+ compatible = "xlnx,v-smpte-uhdsdi-rx-ss-2.0";
+ interrupt-parent = <>;
+ interrupts = <0 89 4>;
+ reg = <0x8000 0x1>;
+ xlnx,include-edh;
+ xlnx,line-rate = ;
+ clocks = <_1>, <_1>, <_2>;
+ clock-names = "s_axi_aclk", "sdi_rx_clk", "video_out_clk";
+ xlnx,bpc = <10>;
+
+ ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+ reg = <0>;
+ sdirx_out: endpoint {
+remote-endpoint = <_sdirx_in>;
+ };
+};
+ };
+};
+...
diff --git a/include/dt-bindings/media/xilinx-sdi.h
b/include/dt-bindings/media/xilinx-sdi.h
new file mode 100644
index ..11938fade041
--- /dev/null
+++
[PATCH v3 1/3] v4l2-dv-timings: Add timings for 1920x1080P48 and 4KP48
Add the timing entry for 1920x1080p48, 3840x2160p48 and 4096x2160p48
from CTA-861-G.
1920x1080p48 is VIC 111.
3840x2160P48 is VIC 114.
4096x2160P48 is VIC 115.
Signed-off-by: Vishal Sagar
---
v3
- Added for first time
include/uapi/linux/v4l2-dv-timings.h | 31 +++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/v4l2-dv-timings.h
b/include/uapi/linux/v4l2-dv-timings.h
index b52b67c62562..6ceaa7841923 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -167,6 +167,16 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 20) \
}
+#define V4L2_DV_BT_CEA_1920X1080P48 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(1920, 1080, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+ 14850, 638, 44, 148, 4, 5, 36, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, \
+ V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+ V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 111) \
+}
+
#define V4L2_DV_BT_CEA_1920X1080P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(1920, 1080, 0, \
@@ -229,6 +239,16 @@
{ 0, 0 }, 95, 1) \
}
+#define V4L2_DV_BT_CEA_3840X2160P48 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+ 59400, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, \
+ V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+ V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 114) \
+}
+
#define V4L2_DV_BT_CEA_3840X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
@@ -278,6 +298,16 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 100) \
}
+#define V4L2_DV_BT_CEA_4096X2160P48 { \
+ .type = V4L2_DV_BT_656_1120, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
+ 59400, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
+ V4L2_DV_BT_STD_CEA861, \
+ V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO | \
+ V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 115) \
+}
+
#define V4L2_DV_BT_CEA_4096X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
@@ -297,7 +327,6 @@
V4L2_DV_FL_HAS_CEA861_VIC, { 0, 0 }, 102) \
}
-
/* VESA Discrete Monitor Timings as per version 1.0, revision 12 */
#define V4L2_DV_BT_DMT_640X350P85 { \
--
2.21.0
[PATCH -next] lib: fix test_hmm.c reference after free
From: Randy Dunlap Coccinelle scripts report the following errors: lib/test_hmm.c:523:20-26: ERROR: reference preceded by free on line 521 lib/test_hmm.c:524:21-27: ERROR: reference preceded by free on line 521 lib/test_hmm.c:523:28-35: ERROR: devmem is NULL but dereferenced. lib/test_hmm.c:524:29-36: ERROR: devmem is NULL but dereferenced. Fix these by using the local variable 'res' instead of devmem. Signed-off-by: Randy Dunlap Cc: Jérôme Glisse Cc: linux...@kvack.org Cc: Ralph Campbell --- lib/test_hmm.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- linux-next-20200617.orig/lib/test_hmm.c +++ linux-next-20200617/lib/test_hmm.c @@ -520,8 +520,7 @@ static bool dmirror_allocate_chunk(struc err_free: kfree(devmem); err_release: - release_mem_region(devmem->pagemap.res.start, - resource_size(>pagemap.res)); + release_mem_region(res->start, resource_size(res)); err: mutex_unlock(>devmem_lock); return false;
Re: [pipe] 566d136289: stress-ng.tee.ops_per_sec -84.7% regression
On 2020/06/18 9:51, kernel test robot wrote:
> FYI, we noticed a -84.7% regression of stress-ng.tee.ops_per_sec due to
> commit:
>
>
> commit: 566d136289dc57816ac290de87a9a0f7d9bd3cbb ("pipe: Fix pipe_full() test
> in opipe_prep().")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
This would be because the test case shows higher performance if the pipe writer
does busy wait.
This commit fixed an unkillable busy wait bug when the pipe reader does not try
to read.
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot
We can't fix the issue. ;-)
mmotm 2020-06-17-22-17 uploaded
The mm-of-the-moment snapshot 2020-06-17-22-17 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.8-rc1: (patches marked "*" will be included in linux-next) origin.patch * openrisc-fix-boot-oops-when-debug_vm-is-enabled.patch * mm-do_swap_page-fix-up-the-error-code-instantiation.patch * mm-slab-use-memzero_explicit-in-kzfree.patch * mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch * mm-swap-fix-for-mm-workingset-age-nonresident-information-alongside-anonymous-pages.patch * mm-memory-fix-io-cost-for-anonymous-page.patch * mm-fix-swap-cache-node-allocation-mask.patch * mm-memcontrol-handle-div0-crash-race-condition-in-memorylow.patch * mm-memcontrol-fix-do-not-put-the-css-reference.patch * mm-memcg-prevent-missed-memorylow-load-tears.patch * docs-mm-gup-minor-documentation-update.patch * doc-thp-cow-fault-no-longer-allocate-thp.patch * mm-compaction-make-capture-control-handling-safe-wrt-interrupts.patch * kexec-do-not-verify-the-signature-without-the-lockdown-or-mandatory-signature.patch * ocfs2-avoid-inode-removed-while-nfsd-access-it.patch * ocfs2-load-global_inode_alloc.patch * ocfs2-fix-panic-on-nfs-server-over-ocfs2.patch * ocfs2-fix-value-of-ocfs2_invalid_slot.patch * linux-bitsh-fix-unsigned-less-than-zero-warnings.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * checkpatch-test-git_dir-changes.patch * scripts-tagssh-collect-compiled-source-precisely.patch * bloat-o-meter-support-comparing-library-archives.patch * ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch * ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch * drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch * ramfs-support-o_tmpfile.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * mm-treewide-rename-kzfree-to-kfree_sensitive.patch * mm-ksize-should-silently-accept-a-null-pointer.patch * mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch * mm-slub-make-some-slub_debug-related-attributes-read-only.patch * mm-slub-remove-runtime-allocation-order-changes.patch * mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch * mm-slub-make-reclaim_account-attribute-read-only.patch * mm-slub-introduce-static-key-for-slub_debug.patch * mm-slub-introduce-kmem_cache_debug_flags.patch * mm-slub-extend-checks-guarded-by-slub_debug-static-key.patch * mm-slab-slub-move-and-improve-cache_from_obj.patch * mm-kcsan-instrument-slab-slub-free-with-assert_exclusive_access.patch * mm-memcg-factor-out-memcg-and-lruvec-level-changes-out-of-__mod_lruvec_state.patch * mm-memcg-prepare-for-byte-sized-vmstat-items.patch * mm-memcg-convert-vmstat-slab-counters-to-bytes.patch * mm-slub-implement-slub-version-of-obj_to_index.patch * mm-memcontrol-decouple-reference-counting-from-page-accounting.patch * mm-memcg-slab-obj_cgroup-api.patch * mm-memcg-slab-allocate-obj_cgroups-for-non-root-slab-pages.patch * mm-memcg-slab-save-obj_cgroup-for-non-root-slab-objects.patch * mm-memcg-slab-charge-individual-slab-objects-instead-of-pages.patch * mm-memcg-slab-deprecate-memorykmemslabinfo.patch * mm-memcg-slab-move-memcg_kmem_bypass-to-memcontrolh.patch * mm-memcg-slab-use-a-single-set-of-kmem_caches-for-all-accounted-allocations.patch * mm-memcg-slab-simplify-memcg-cache-creation.patch * mm-memcg-slab-remove-memcg_kmem_get_cache.patch * mm-memcg-slab-deprecate-slab_root_caches.patch *
Re: [PATCH v3 1/2] ALSA: hda/realtek: Add COEF controlled micmute LED support
> On Jun 17, 2020, at 23:50, Takashi Iwai wrote: > > On Wed, 17 Jun 2020 17:24:30 +0200, > Kai-Heng Feng wrote: >> >> >> >>> On Jun 17, 2020, at 19:55, Takashi Iwai wrote: >>> >>> On Wed, 17 Jun 2020 12:29:01 +0200, >>> Kai-Heng Feng wrote: Currently, HDA codec LED class can only be used by GPIO controlled LED. However, there are some new systems that control LED via COEF instead of GPIO. In order to support those systems, create a new helper that can be facilitated by both COEF controlled and GPIO controlled LED. In addition to that, add LED_CORE_SUSPENDRESUME flag since some systems don't restore the LED properly after suspend. Signed-off-by: Kai-Heng Feng >>> >>> Thanks for the quick follow up, the issues I pointed were fixed. >>> >>> But, now looking at the code change again, I'm no longer sure whether >>> it's the right move. >>> >>> Basically, the led cdev should serve only for turning on/off the LED >>> as given. But your patch changes it to call the generic mixer >>> updater, which is rather the one who would call the led cdev state >>> update itself. That is, it's other way round. >>> >>> IMO, what we need is to make all places calling >>> snd_hda_gen_add_micmute_led() to create led cdev, and change those >>> calls with snd_hda_gen_fixup_micmute_led(). >> >> Ok, so it's the same as patch v1. >> How should we handle vendors other than HP? >> Only create led cdev if the ID matches to HP? > > It's fine to create a LED classdev for other vendors, too. But the > problem is that it wasn't consistent. With the LED classdev, we > should use only cdev, instead of mixing up different ways. Ok, now I get what you meant... > > I wrote a few patches to convert those mic-mute LED stuff to classdev, > including some cleanups. The patches are found in > topic/hda-micmute-led branch of sound git tree. Could you check it? > > Note that it's totally untested. Also it doesn't contain yet > LED_CORE_SUSPENDRESUME, which should be done in another patch in > anyway. Other than LED_CORE_SUSPENDRESUME, it works great! Tested-by: Kai-Heng Feng > >>> It'll be a bit more changes and likely not fitting with 5.8, but the >>> whole result will be more consistent. >> >> A bit off topic, but do you think it's reasonable to also create led cdev >> for mute LED, in addition to micmute LED? >> I just found that the LEDs are still on during system suspend, and led cdev >> has the ability to turn off the LEDs on system suspend. > > Yes, it makes sense, too. But the playback mute handling is a bit > more complicated than the mic-mute LED because it's implemented with a > vmaster hook. I'll take a look later. Thanks. I'll be happy to test it. Kai-Heng > > > thanks, > > Takashi
Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
On Thu, 18 Jun 2020 at 10:29, Sumit Garg wrote:
>
> Hi Jerome,
>
> On Wed, 17 Jun 2020 at 20:46, Jerome Forissier wrote:
> >
> >
> >
> > On 6/17/20 3:58 PM, Sumit Garg wrote:
> > > Hi Maxim,
> > >
> > > On Thu, 4 Jun 2020 at 23:28, Maxim Uvarov wrote:
> > >>
> > >> With the evolving use-cases for TEE bus, now it's required to support
> > >> multi-stage enumeration process. But using a simple index doesn't
> > >> suffice this requirement and instead leads to duplicate sysfs entries.
> > >> So instead switch to use more informative device UUID for sysfs entry
> > >> like:
> > >> /sys/bus/tee/devices/optee-ta-
> > >>
> > >> Signed-off-by: Maxim Uvarov
> > >> Reviewed-by: Sumit Garg
> > >> ---
> > >> Documentation/ABI/testing/sysfs-bus-optee-devices | 8
> > >> MAINTAINERS | 1 +
> > >> drivers/tee/optee/device.c| 9 ++---
> > >> 3 files changed, 15 insertions(+), 3 deletions(-)
> > >> create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices
> > >>
> > >> diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> b/Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> new file mode 100644
> > >> index ..0ae04ae5374a
> > >> --- /dev/null
> > >> +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> @@ -0,0 +1,8 @@
> > >> +What: /sys/bus/tee/devices/optee-ta-/
> > >> +Date: May 2020
> > >> +KernelVersion 5.7
> > >> +Contact:tee-...@lists.linaro.org
> > >> +Description:
> > >> + OP-TEE bus provides reference to registered drivers
> > >> under this directory. The
> > >> + matches Trusted Application (TA) driver and
> > >> corresponding TA in secure OS. Drivers
> > >> + are free to create needed API under optee-ta-
> > >> directory.
> > >> diff --git a/MAINTAINERS b/MAINTAINERS
> > >> index ecc0749810b0..6717afef2de3 100644
> > >> --- a/MAINTAINERS
> > >> +++ b/MAINTAINERS
> > >> @@ -12516,6 +12516,7 @@ OP-TEE DRIVER
> > >> M: Jens Wiklander
> > >> L: tee-...@lists.linaro.org
> > >> S: Maintained
> > >> +F: Documentation/ABI/testing/sysfs-bus-optee-devices
> > >> F: drivers/tee/optee/
> > >>
> > >> OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
> > >> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> > >> index e3a148521ec1..23d264c8146e 100644
> > >> --- a/drivers/tee/optee/device.c
> > >> +++ b/drivers/tee/optee/device.c
> > >> @@ -65,7 +65,7 @@ static int get_devices(struct tee_context *ctx, u32
> > >> session,
> > >> return 0;
> > >> }
> > >>
> > >> -static int optee_register_device(const uuid_t *device_uuid, u32
> > >> device_id)
> > >> +static int optee_register_device(const uuid_t *device_uuid)
> > >> {
> > >> struct tee_client_device *optee_device = NULL;
> > >> int rc;
> > >> @@ -75,7 +75,10 @@ static int optee_register_device(const uuid_t
> > >> *device_uuid, u32 device_id)
> > >> return -ENOMEM;
> > >>
> > >> optee_device->dev.bus = _bus_type;
> > >> - dev_set_name(_device->dev, "optee-clnt%u", device_id);
> > >> + if (dev_set_name(_device->dev, "optee-ta-%pUl",
> > >> device_uuid)) {
> > >
> > > You should be using format specifier as: "%pUb" instead of "%pUl" as
> > > UUID representation for TAs is in big endian format. See below:
> >
> > Where does device_uuid come from? If it comes directly from OP-TEE, then
> > it should be a pointer to the following struct:
> >
> > typedef struct
> > {
> > uint32_t timeLow;
> > uint16_t timeMid;
> > uint16_t timeHiAndVersion;
> > uint8_t clockSeqAndNode[8];
> > } TEE_UUID;
> >
> > (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
> >
> > - The spec does not mandate any particular endianness and simply warns
> > about possible issues if secure and non-secure worlds differ in endianness.
> > - OP-TEE uses %pUl assuming that host order is little endian (that is
> > true for the Arm platforms that run OP-TEE currently). By the same logic
> > %pUl should be fine in the kernel.
I think Linux adheres to this RFC [1] for UUID byte order. See below
snippet from section: "Layout and Byte Order":
The fields are encoded as 16 octets, with the sizes and order of the
fields defined above, and with each field encoded with the Most
Significant Byte first (known as network byte order). Note that the
field names, particularly for multiplexed fields, follow historical
practice.
-Sumit
[1] https://tools.ietf.org/html/rfc4122
> > - On the other hand, the UUID in a Trusted App header is always encoded
> > big endian by the Python script that signs and optionally encrypts the
> > TA. This should not have any visible impact on UUIDs exchanged between
> > the secure and non-secure world though.
> >
> > So I am wondering why you had to use %pUb. There must be some
> > inconsistency somewhere :-/
>
> Yes there is.
Re: [PATCH] sparse: use identifiers to define address spaces
On Thu, Jun 18, 2020 at 03:22:15AM +0200, Miguel Ojeda wrote: > Hi Luc, Hi Miguel, > On Thu, Jun 18, 2020 at 12:02 AM Luc Van Oostenryck > wrote: > > > > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h > > index 21aed0981edf..e368384445b6 100644 > > --- a/include/linux/compiler_types.h > > +++ b/include/linux/compiler_types.h > > @@ -5,20 +5,20 @@ > > #ifndef __ASSEMBLY__ > > > > #ifdef __CHECKER__ > > -# define __user__attribute__((noderef, address_space(1))) > > # define __kernel __attribute__((address_space(0))) > > +# define __user__attribute__((noderef, > > address_space(__user))) > > I guess `__kernel` moves to the first place since it uses the first > address space? No, there is no really an order between address spaces. Even before this patch, the number were only used as an ID to distinguish them from each other. I just moved __kernel above because it is quite different from the others because it's the default one, and so: * it's never displayed * it's normally not needed, nor in type annotations, nor in cast between address spaces. The only time it's needed is when it's combined with a typeof to express "the same type as this one but without the address space" * it can't be defined with a name, '0' must be used. So, it seemed strange to me to have it in the middle of the other ones. -- Luc
Re: [Tee-dev] [PATCHv8 1/3] optee: use uuid for sysfs driver entry
Hi Jerome,
On Wed, 17 Jun 2020 at 20:46, Jerome Forissier wrote:
>
>
>
> On 6/17/20 3:58 PM, Sumit Garg wrote:
> > Hi Maxim,
> >
> > On Thu, 4 Jun 2020 at 23:28, Maxim Uvarov wrote:
> >>
> >> With the evolving use-cases for TEE bus, now it's required to support
> >> multi-stage enumeration process. But using a simple index doesn't
> >> suffice this requirement and instead leads to duplicate sysfs entries.
> >> So instead switch to use more informative device UUID for sysfs entry
> >> like:
> >> /sys/bus/tee/devices/optee-ta-
> >>
> >> Signed-off-by: Maxim Uvarov
> >> Reviewed-by: Sumit Garg
> >> ---
> >> Documentation/ABI/testing/sysfs-bus-optee-devices | 8
> >> MAINTAINERS | 1 +
> >> drivers/tee/optee/device.c| 9 ++---
> >> 3 files changed, 15 insertions(+), 3 deletions(-)
> >> create mode 100644 Documentation/ABI/testing/sysfs-bus-optee-devices
> >>
> >> diff --git a/Documentation/ABI/testing/sysfs-bus-optee-devices
> >> b/Documentation/ABI/testing/sysfs-bus-optee-devices
> >> new file mode 100644
> >> index ..0ae04ae5374a
> >> --- /dev/null
> >> +++ b/Documentation/ABI/testing/sysfs-bus-optee-devices
> >> @@ -0,0 +1,8 @@
> >> +What: /sys/bus/tee/devices/optee-ta-/
> >> +Date: May 2020
> >> +KernelVersion 5.7
> >> +Contact:tee-...@lists.linaro.org
> >> +Description:
> >> + OP-TEE bus provides reference to registered drivers under
> >> this directory. The
> >> + matches Trusted Application (TA) driver and corresponding
> >> TA in secure OS. Drivers
> >> + are free to create needed API under optee-ta-
> >> directory.
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index ecc0749810b0..6717afef2de3 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -12516,6 +12516,7 @@ OP-TEE DRIVER
> >> M: Jens Wiklander
> >> L: tee-...@lists.linaro.org
> >> S: Maintained
> >> +F: Documentation/ABI/testing/sysfs-bus-optee-devices
> >> F: drivers/tee/optee/
> >>
> >> OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
> >> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> >> index e3a148521ec1..23d264c8146e 100644
> >> --- a/drivers/tee/optee/device.c
> >> +++ b/drivers/tee/optee/device.c
> >> @@ -65,7 +65,7 @@ static int get_devices(struct tee_context *ctx, u32
> >> session,
> >> return 0;
> >> }
> >>
> >> -static int optee_register_device(const uuid_t *device_uuid, u32 device_id)
> >> +static int optee_register_device(const uuid_t *device_uuid)
> >> {
> >> struct tee_client_device *optee_device = NULL;
> >> int rc;
> >> @@ -75,7 +75,10 @@ static int optee_register_device(const uuid_t
> >> *device_uuid, u32 device_id)
> >> return -ENOMEM;
> >>
> >> optee_device->dev.bus = _bus_type;
> >> - dev_set_name(_device->dev, "optee-clnt%u", device_id);
> >> + if (dev_set_name(_device->dev, "optee-ta-%pUl",
> >> device_uuid)) {
> >
> > You should be using format specifier as: "%pUb" instead of "%pUl" as
> > UUID representation for TAs is in big endian format. See below:
>
> Where does device_uuid come from? If it comes directly from OP-TEE, then
> it should be a pointer to the following struct:
>
> typedef struct
> {
> uint32_t timeLow;
> uint16_t timeMid;
> uint16_t timeHiAndVersion;
> uint8_t clockSeqAndNode[8];
> } TEE_UUID;
>
> (GlobalPlatform TEE Internal Core API spec v1.2.1 section 3.2.4)
>
> - The spec does not mandate any particular endianness and simply warns
> about possible issues if secure and non-secure worlds differ in endianness.
> - OP-TEE uses %pUl assuming that host order is little endian (that is
> true for the Arm platforms that run OP-TEE currently). By the same logic
> %pUl should be fine in the kernel.
> - On the other hand, the UUID in a Trusted App header is always encoded
> big endian by the Python script that signs and optionally encrypts the
> TA. This should not have any visible impact on UUIDs exchanged between
> the secure and non-secure world though.
>
> So I am wondering why you had to use %pUb. There must be some
> inconsistency somewhere :-/
Yes there is. Linux stores UUID in big endian format (16 byte octets)
and OP-TEE stores UUID in little endian format (in form of struct you
referenced above).
And format conversion APIs [1] in OP-TEE OS are used while passing
UUID among Linux and OP-TEE.
So we need to use %pUb in case of Linux and %pUl in case of OP-TEE.
[1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c
-Sumit
>
> --
> Jerome
>
> >
> > # ls /sys/bus/tee/devices/
> > optee-ta-405b6ad9-e5c3-e321-8794-1002a5d5c61b
> > optee-ta-71d950bc-c9d4-c442-82cb-343fb7f37896
> > optee-ta-e70f4af0-5d1f-9b4b-abf7-619b85b4ce8c
> >
> > While UUID for fTPM TA is in big endian format:
> > bc50d971-d4c9-42c4-82cb-343fb7f37896
> >
> > Sorry that I missed it during review and
Re: [PATCH v6 0/6] DVFS for IO devices on sdm845 and sc7180
Hey Matthias, thanks for summarizing this. On 6/18/2020 3:45 AM, Matthias Kaehlcke wrote: What is the plan for landing these, it seems not all must/should go through the QCOM tree. My guesses: tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state spi: spi-geni-qcom: Use OPP API to set clk/perf state QCOM tree due to shared dependency on change in include/linux/qcom-geni-se.h That's correct, Bjorn/Andy, can these be pulled in now for 5.9? They have acks from Greg for serial and Mark for the spi patch. drm/msm/dpu: Use OPP API to set clk/perf state drm/msm: dsi: Use OPP API to set clk/perf state drm/msm tree Correct, the dsi patch is still not reviewed by Rob, so once that's done, I am guessing Rob would pull both of these. media: venus: core: Add support for opp tables/perf voting venus tree correct, this is pending review/ack from Stan. spi: spi-qcom-qspi: Use OPP API to set clk/perf state SPI tree Right, Mark has this acked, I am guessing he will pull this in at some point. thanks, Rajendra Does this make sense or are there any dependencies I'm missing? Thanks Matthias On Mon, Jun 15, 2020 at 05:32:38PM +0530, Rajendra Nayak wrote: Changes in v6: 1. rebased on 5.8-rc1, no functional change. Changes in v5: 1. Opp cleanup path fixed up across drivers Changes in v4: 1. Fixed all review feedback on v3 2. Dropped the dts patches, will post as a seperate series once driver changes are reviewed and merged. The driver changes without DT updates to include OPP tables will have zero functional change. 3. Dropped the mmc/sdhc patch, which is a standalone patch. will repost if needed seperately. Changes in v3: 1. Added better error handling for dev_pm_opp_of_add_table() 2. Some minor changes and fixes in 'PATCH 12/17' as compared to v2 3. Dropped the mmc patch picked up by Ulf [2] Changes in v2: 1. Added error handling for dev_pm_opp_set_clkname() and dev_pm_opp_of_add_table() 2. Used dev_pm_opp_put_clkname() in the cleanup path 3. Dropped the OPP patch pulled in by Viresh [1] 4. Dropped the UFS patches since they had some major rework needed because of changes that were merged in the merge window and I don't have a UFS device currently to validate the changes. We have had support added in the OPP core for a while now to support DVFS for IO devices, and this series uses that infrastructure to add DVFS support for various IO devices in sdm845 and sc7180 SoCs. [1] https://lkml.org/lkml/2020/4/14/98 [2] https://lore.kernel.org/patchwork/patch/1226381/ Rajendra Nayak (6): tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state spi: spi-geni-qcom: Use OPP API to set clk/perf state drm/msm/dpu: Use OPP API to set clk/perf state drm/msm: dsi: Use OPP API to set clk/perf state media: venus: core: Add support for opp tables/perf voting spi: spi-qcom-qspi: Use OPP API to set clk/perf state drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 26 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h| 4 ++ drivers/gpu/drm/msm/dsi/dsi.h | 2 + drivers/gpu/drm/msm/dsi/dsi_cfg.c | 4 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 58 ++ drivers/media/platform/qcom/venus/core.c | 43 --- drivers/media/platform/qcom/venus/core.h | 5 +++ drivers/media/platform/qcom/venus/pm_helpers.c | 54 ++-- drivers/spi/spi-geni-qcom.c| 26 ++-- drivers/spi/spi-qcom-qspi.c| 28 - drivers/tty/serial/qcom_geni_serial.c | 34 --- include/linux/qcom-geni-se.h | 4 ++ 13 files changed, 268 insertions(+), 23 deletions(-) -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
linux-next: Tree for Jun 18
Hi all,
News: there will be no linux-next release tomorrow.
Changes since 20200617:
My fixes tree contains:
4cb4bfffe2c1 ("device_cgroup: Fix RCU list debugging warning")
The ipsec tree gained conflicts against Linus' tree.
The amdgpu tree still had its build failure so I used the version from
next-20200616.
The pidfd tree gained a conflict against the powerpc-fixes tree.
Non-merge commits (relative to Linus' tree): 1549
1605 files changed, 252975 insertions(+), 21474 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).
Below is a summary of the state of the merge.
I am currently merging 320 trees (counting Linus' and 82 trees of bug
fix patches pending for the current merge release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwell
$ git checkout master
$ git reset --hard stable
Merging origin/master (1b5044021070 Merge tag 'dma-mapping-5.8-3' of
git://git.infradead.org/users/hch/dma-mapping)
Merging fixes/master (df8cb0ea9423 device_cgroup: Fix RCU list debugging
warning)
Merging kbuild-current/fixes (0f50d21ade11 scripts: Fix typo in
headers_install.sh)
Merging arc-current/for-curr (040ece2a3c15 ARC: build: remove deprecated toggle
for arc700 builds)
Merging arm-current/fixes (3866f217aaa8 ARM: 8977/1: ptrace: Fix mask for thumb
breakpoint hook)
Merging arm-soc-fixes/arm/fixes (99706d62fb50 Merge tag
'omap-for-v5.7/cpsw-fixes-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes)
Merging uniphier-fixes/fixes (0e698dfa2822 Linux 5.7-rc4)
Merging arm64-fixes/for-next/fixes (b9249cba25a5 arm64: bti: Require clang >=
10.0.1 for in-kernel BTI support)
Merging m68k-current/for-linus (3381df095419 m68k: tools: Replace zero-length
array with flexible-array member)
Merging powerpc-fixes/fixes (b55129f97aee powerpc/8xx: Provide ptep_get() with
16k pages)
Merging s390-fixes/fixes (b3583fca5fb6 s390: fix syscall_get_error for compat
processes)
Merging sparc/master (b3a9e3b9622a Linux 5.8-rc1)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty
inodes after removing key)
Merging net/master (ef7232da6bcd ionic: export features for vlans to use)
Merging bpf/master (8030e250d882 bpf: Document optval > PAGE_SIZE behavior for
sockopt hooks)
Merging ipsec/master (be01369859b8 esp, ah: modernize the crypto algorithm
selections)
CONFLICT (content): Merge conflict in net/ipv6/Kconfig
CONFLICT (content): Merge conflict in net/ipv4/Kconfig
Merging netfilter/master (c92cbaea3cc0 net: dsa: sja1105: fix PTP timestamping
with large tc-taprio cycles)
Merging ipvs/master (bdc48fa11e46 checkpatch/coding-style: deprecate 80-column
warning)
Merging wireless-drivers/master (b3a9e3b9622a Linux 5.8-rc1)
Merging mac80211/master (59d4bfc1e2c0 net: fix wiki website url mac80211 and
wireless files)
Merging rdma-fixes/for-rc (b3a9e3b9622a Linux 5.8-rc1)
Merging sound-current/for-linus (b2c22910fe5a ALSA: hda/realtek: Add mute LED
and micmute LED support for HP systems)
Merging sound-asoc-fixes/for-linus (a884e26fea98 Merge remote-tracking branch
'asoc/for-5.8' into asoc-linus)
Merging regmap-fixes/for-linus (82228364de4a Merge remote-tracking branch
'regmap/for-5.8' into regmap-linus)
Merging regulator-fixes/for-linus (1b3bcca20858 regulator: mt6358: Remove
BROKEN dependency)
Merging spi-fixes/for-linus (1c8794921564 Merge remote-tracking branch
'spi/for-5.8' into spi-linus)
Merging pci-current/for-linus (b3a9e3
Re: [PATCH 00/12] KVM: arm64: Support stage2 hardware DBM
Hi, On 2020/6/16 17:35, Keqian Zhu wrote: > This patch series add support for stage2 hardware DBM, and it is only > used for dirty log for now. > > It works well under some migration test cases, including VM with 4K > pages or 2M THP. I checked the SHA256 hash digest of all memory and > they keep same for source VM and destination VM, which means no dirty > pages is missed under hardware DBM. > > Some key points: > > 1. Only support hardware updates of dirty status for PTEs. PMDs and PUDs >are not involved for now. > > 2. About *performance*: In RFC patch, I have mentioned that for every 64GB >memory, KVM consumes about 40ms to scan all PTEs to collect dirty log. > >Initially, I plan to solve this problem using parallel CPUs. However >I faced two problems. > >The first is bottleneck of memory bandwith. Single thread will occupy >bandwidth about 500GB/s, we can support about 4 parallel threads at >most, so the ideal speedup ratio is low. Aha, I make it wrong here. I test it again, and find that speedup ratio can be about 23x when I use 32 CPUs to scan PTs (takes about 5ms when scanning PTs of 200GB RAM). > >The second is huge impact on other CPUs. To scan PTs quickly, I use >smp_call_function_many, which is based on IPI, to dispatch workload >on other CPUs. Though it can complete work in time, the interrupt is >disabled during scaning PTs, which has huge impact on other CPUs. I think we can divide scanning workload into smaller ones, which can disable and enable interrupts periodly. > >Now, I make hardware dirty log can be dynamic enabled and disabled. >Userspace can enable it before VM migration and disable it when >remaining dirty pages is little. Thus VM downtime is not affected. BTW, we can reserve this interface for userspace if CPU computing resources are not enough. Thanks, Keqian > > > 3. About correctness: Only add DBM bit when PTE is already writable, so >we still have readonly PTE and some mechanisms which rely on readonly >PTs are not broken. > > 4. About PTs modification races: There are two kinds of PTs modification. > >The first is adding or clearing specific bit, such as AF or RW. All >these operations have been converted to be atomic, avoid covering >dirty status set by hardware. > >The second is replacement, such as PTEs unmapping or changement. All >these operations will invoke kvm_set_pte finally. kvm_set_pte have >been converted to be atomic and we save the dirty status to underlying >bitmap if dirty status is coverred. > > > Keqian Zhu (12): > KVM: arm64: Add some basic functions to support hw DBM > KVM: arm64: Modify stage2 young mechanism to support hw DBM > KVM: arm64: Report hardware dirty status of stage2 PTE if coverred > KVM: arm64: Support clear DBM bit for PTEs > KVM: arm64: Add KVM_CAP_ARM_HW_DIRTY_LOG capability > KVM: arm64: Set DBM bit of PTEs during write protecting > KVM: arm64: Scan PTEs to sync dirty log > KVM: Omit dirty log sync in log clear if initially all set > KVM: arm64: Steply write protect page table by mask bit > KVM: arm64: Save stage2 PTE dirty status if it is coverred > KVM: arm64: Support disable hw dirty log after enable > KVM: arm64: Enable stage2 hardware DBM > > arch/arm64/include/asm/kvm_host.h | 11 + > arch/arm64/include/asm/kvm_mmu.h | 56 +++- > arch/arm64/include/asm/sysreg.h | 2 + > arch/arm64/kvm/arm.c | 22 +- > arch/arm64/kvm/mmu.c | 411 -- > arch/arm64/kvm/reset.c| 14 +- > include/uapi/linux/kvm.h | 1 + > tools/include/uapi/linux/kvm.h| 1 + > virt/kvm/kvm_main.c | 7 +- > 9 files changed, 499 insertions(+), 26 deletions(-) >
memory leak in macvlan_hash_add_source
Hello, syzbot found the following crash on: HEAD commit:7ae77150 Merge tag 'powerpc-5.8-1' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11fbb45610 kernel config: https://syzkaller.appspot.com/x/.config?x=9a1aa05456dfd557 dashboard link: https://syzkaller.appspot.com/bug?extid=62100d232f618b7da606 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=163092a910 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12caed7a10 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+62100d232f618b7da...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x888115ac4080 (size 64): comm "syz-executor882", pid 6646, jiffies 4294954688 (age 14.840s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 20 ee 41 15 81 88 ff ff .A. 00 09 92 15 81 88 ff ff aa aa aa aa aa 23 00 00 .#.. backtrace: [] kmalloc include/linux/slab.h:555 [inline] [ ] macvlan_hash_add_source+0x52/0xe0 drivers/net/macvlan.c:161 [<5aee7a07>] macvlan_changelink_sources+0x8a/0x1f0 drivers/net/macvlan.c:1355 [ ] macvlan_common_newlink+0x21a/0x570 drivers/net/macvlan.c:1463 [ ] __rtnl_newlink+0x843/0xb10 net/core/rtnetlink.c:3340 [<9677515c>] rtnl_newlink+0x49/0x70 net/core/rtnetlink.c:3398 [ ] rtnetlink_rcv_msg+0x173/0x4b0 net/core/rtnetlink.c:5461 [ ] netlink_rcv_skb+0x5a/0x180 net/netlink/af_netlink.c:2469 [ ] netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] [ ] netlink_unicast+0x20a/0x2f0 net/netlink/af_netlink.c:1329 [<6a00463c>] netlink_sendmsg+0x2b5/0x560 net/netlink/af_netlink.c:1918 [ ] sock_sendmsg_nosec net/socket.c:652 [inline] [ ] sock_sendmsg+0x4c/0x60 net/socket.c:672 [<0ca330a5>] sys_sendmsg+0x118/0x2f0 net/socket.c:2352 [<6a5fc310>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2406 [<4d3b2570>] __sys_sendmmsg+0xda/0x230 net/socket.c:2496 [ ] __do_sys_sendmmsg net/socket.c:2525 [inline] [ ] __se_sys_sendmmsg net/socket.c:2522 [inline] [ ] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2522 [<333adef2>] do_syscall_64+0x6e/0x220 arch/x86/entry/common.c:295 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH] [net/sched]: Remove redundant condition in qdisc_graft
parent cannot be NULL here since its in the else part of the if (parent == NULL) condition. Remove the extra check on parent pointer. Signed-off-by: Gaurav Singh --- net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c index 9a3449b56bd6..be93ebcdb18d 100644 --- a/net/sched/sch_api.c +++ b/net/sched/sch_api.c @@ -1094,7 +1094,7 @@ static int qdisc_graft(struct net_device *dev, struct Qdisc *parent, /* Only support running class lockless if parent is lockless */ if (new && (new->flags & TCQ_F_NOLOCK) && - parent && !(parent->flags & TCQ_F_NOLOCK)) + !(parent->flags & TCQ_F_NOLOCK)) qdisc_clear_nolock(new); if (!cops || !cops->graft) -- 2.17.1
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> From: Anson Huang > Sent: Thursday, June 18, 2020 11:18 AM > > > From: Aisheng Dong > > Sent: 2020年6月18日 11:09 > > > > > From: Anson Huang > > > Sent: Wednesday, June 17, 2020 8:36 PM > > > > > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > > > > > > > From: Anson Huang > > > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > > > > > i.MX common clock drivers may support module build, so it is NOT > > > > > selected by default, for ARCH_MXC ARMv7 platforms, need to > > > > > select it manually to make build pass. > > > > > > > > > > Signed-off-by: Anson Huang > > > > > > > > Can't the original def_xxx work? > > > > > > > > config MXC_CLK > > > > tristate > > > > def_tristate ARCH_MXC > > > > > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers > > > are selected as module, so it does NOT meet the requirement of > > > module support. Below is from .config when all > > > i.MX8 SoCs clock drivers are configured to module. > > > > > > CONFIG_MXC_CLK=y > > > CONFIG_MXC_CLK_SCU=m > > > CONFIG_CLK_IMX8MM=m > > > CONFIG_CLK_IMX8MN=m > > > CONFIG_CLK_IMX8MP=m > > > CONFIG_CLK_IMX8MQ=m > > > CONFIG_CLK_IMX8QXP=m > > > > > > > It works at my side. > > Below is my changes based on your patchset: > > $ git diff > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig > > index > > 47b10d20f411..e7d7b90e2cf8 100644 > > --- a/arch/arm/mach-imx/Kconfig > > +++ b/arch/arm/mach-imx/Kconfig > > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC > > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > > ARM_SINGLE_ARMV7M > > select ARCH_SUPPORTS_BIG_ENDIAN > > select CLKSRC_IMX_GPT > > - select MXC_CLK > > select GENERIC_IRQ_CHIP > > select GPIOLIB > > select PINCTRL > > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > > 26cedbfe386c..f7b3e3a2cb9f 100644 > > --- a/drivers/clk/imx/Kconfig > > +++ b/drivers/clk/imx/Kconfig > > @@ -3,6 +3,7 @@ > > config MXC_CLK > > tristate "IMX clock" > > depends on ARCH_MXC > > + def_tristate ARCH_MXC > > > > config MXC_CLK_SCU > > tristate "IMX SCU clock" > > > > I guess you tried imx_v6_v7_defconfig? It does NOT work for ARM64 defconfig > when we try to make CONFIG_MXC_CLK=m, Below are my change, you can see > in .config, even all i.MX8 SoCs clock drivers are configured to module, the > CONFIG_MXC_CLK is still =y, but the expected result is =m. > It works at my side because it can manually selected as m or add CONFIG_MXC_CLK=m In defconfig. But now I got your point you want CONFIG_MXC_CLK default to m once define CONFIG_CLK_IMX8X=m in defconfig. > BTW, all i.MX8 SoCs select MXC_CLK in their kconfig, this patch just does the > same thing for i.MX6/7 in common place. > I just noticed for MX6&7, actually CONFIG_MXC_CLK can't be m otherwise we will meet build break. That means CONFIG_MXC_CLK cannot be configurable by users for non-ARM64 platforms. Thus can't use def_tristate and we still need select it under ARCH_MXC. This lightly lose a bit meaning to make this core library as module. IMHO I'd still prefer to builtin those core libraries rather than convert to module. Regards Aisheng > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index > 47b10d2..e7d7b90 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M > select ARCH_SUPPORTS_BIG_ENDIAN > select CLKSRC_IMX_GPT > - select MXC_CLK > select GENERIC_IRQ_CHIP > select GPIOLIB > select PINCTRL > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index > 8222e4b..21e2dbb 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -799,11 +799,11 @@ CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_COMMON_CLK_PWM=y CONFIG_COMMON_CLK_VC5=y > CONFIG_CLK_RASPBERRYPI=m -CONFIG_CLK_IMX8MM=y > -CONFIG_CLK_IMX8MN=y -CONFIG_CLK_IMX8MP=y -CONFIG_CLK_IMX8MQ=y > -CONFIG_CLK_IMX8QXP=y > +CONFIG_CLK_IMX8MM=m > +CONFIG_CLK_IMX8MN=m > +CONFIG_CLK_IMX8MP=m > +CONFIG_CLK_IMX8MQ=m > +CONFIG_CLK_IMX8QXP=m > CONFIG_TI_SCI_CLK=y > CONFIG_COMMON_CLK_QCOM=y > CONFIG_QCOM_A53PLL=y > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > 26cedbf..f7b3e3a 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -3,6 +3,7 @@ > config MXC_CLK > tristate "IMX clock" > depends on ARCH_MXC > + def_tristate ARCH_MXC > > config MXC_CLK_SCU > tristate "IMX SCU clock" > > .config: > CONFIG_MXC_CLK=y > CONFIG_MXC_CLK_SCU=m > CONFIG_CLK_IMX8MM=m > CONFIG_CLK_IMX8MN=m > CONFIG_CLK_IMX8MP=m > CONFIG_CLK_IMX8MQ=m > CONFIG_CLK_IMX8QXP=m > > Anson
[PATCH] kunit: fix KconfigParseError by ignoring CC_VERSION_TEXT
Commit 8b59cd81dc5 ("kbuild: ensure full rebuild when the compiler
is updated") added the environment variable CC_VERSION_TEXT,
parse_from_string() doesn't expect a string and this causes the
failure below:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run --timeout=60
[00:20:12] Configuring KUnit Kernel ...
Generating .config ...
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 347, in
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 257, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 134, in run_tests
config_result = config_tests(linux, config_request)
File "tools/testing/kunit/kunit.py", line 64, in config_tests
success = linux.build_reconfig(request.build_dir, request.make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 161, in
build_reconfig
return self.build_config(build_dir, make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 145, in
build_config
return self.validate_config(build_dir)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 124, in
validate_config
validated_kconfig.read_from_file(kconfig_path)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 89, in
read_from_file
self.parse_from_string(f.read())
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 85, in
parse_from_string
raise KconfigParseError('Failed to parse: ' + line)
kunit_config.KconfigParseError: Failed to parse: CONFIG_CC_VERSION_TEXT="gcc
(GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)"
Signed-off-by: Vitor Massaru Iha
---
tools/testing/kunit/kunit_config.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit_config.py
b/tools/testing/kunit/kunit_config.py
index e75063d603b5..3033520597b6 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -9,6 +9,7 @@
import collections
import re
+CONFIG_IGNORE_CC_VERSION_TEXT = 'CONFIG_CC_VERSION_TEXT'
CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$'
CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+)$'
@@ -79,7 +80,7 @@ class Kconfig(object):
self.add_entry(entry)
continue
- if line[0] == '#':
+ if line[0] == '#' or CONFIG_IGNORE_CC_VERSION_TEXT in
line:
continue
else:
raise KconfigParseError('Failed to parse: ' +
line)
base-commit: 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd
--
2.26.2
[tip:x86/cleanups] BUILD SUCCESS 2accfa69050c2a0d6fc6106f609208b3e9622b26
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cleanups branch HEAD: 2accfa69050c2a0d6fc6106f609208b3e9622b26 cpu/speculation: Add prototype for cpu_show_srbds() elapsed time: 726m configs tested: 109 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig mips ip28_defconfig xtensaxip_kc705_defconfig m68kmvme16x_defconfig armmmp2_defconfig arm ep93xx_defconfig mips xway_defconfig sparcalldefconfig arm mv78xx0_defconfig powerpc mpc83xx_defconfig c6x alldefconfig xtensa defconfig riscv rv32_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20200617 i386 randconfig-a002-20200617 i386 randconfig-a001-20200617 i386 randconfig-a004-20200617 i386 randconfig-a005-20200617 i386 randconfig-a003-20200617 x86_64 randconfig-a015-20200617 x86_64 randconfig-a011-20200617 x86_64 randconfig-a016-20200617 x86_64 randconfig-a014-20200617 x86_64 randconfig-a012-20200617 x86_64 randconfig-a013-20200617 i386 randconfig-a015-20200617 i386 randconfig-a011-20200617 i386 randconfig-a014-20200617 i386 randconfig-a016-20200617 i386 randconfig-a013-20200617 i386 randconfig-a012-20200617 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig umallnoconfig um defconfig um allmodconfig um
Re: [PATCH] [net/sched] Fix null pointer deref skb in tc_ctl_action
On 6/17/20 6:43 PM, Gaurav Singh wrote:
> Add null check for skb
>
Bad choice really.
You have to really understand code intent before trying to fix it.
> Signed-off-by: Gaurav Singh
> ---
> net/sched/act_api.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index 8ac7eb0a8309..fd584821d75a 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -1473,9 +1473,12 @@ static const struct nla_policy
> tcaa_policy[TCA_ROOT_MAX + 1] = {
> static int tc_ctl_action(struct sk_buff *skb, struct nlmsghdr *n,
>struct netlink_ext_ack *extack)
> {
> + if (!skb)
> + return 0;
We do not allow this
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
> +
> struct net *net = sock_net(skb->sk);
> struct nlattr *tca[TCA_ROOT_MAX + 1];
> - u32 portid = skb ? NETLINK_CB(skb).portid : 0;
> + u32 portid = NETLINK_CB(skb).portid;
> int ret = 0, ovr = 0;
>
> if ((n->nlmsg_type != RTM_GETACTION) &&
>
Please compile your patches, do not expect us from doing this.
[PATCH net] net: dsa: bcm_sf2: Fix node reference count
of_find_node_by_name() will do an of_node_put() on the "from" argument.
With CONFIG_OF_DYNAMIC enabled which checks for device_node reference
counts, we would be getting a warning like this:
[6.347230] refcount_t: increment on 0; use-after-free.
[6.352498] WARNING: CPU: 3 PID: 77 at lib/refcount.c:156
refcount_inc_checked+0x38/0x44
[6.360601] Modules linked in:
[6.363661] CPU: 3 PID: 77 Comm: kworker/3:1 Tainted: GW
5.4.46-gb78b3e9956e6 #13
[6.372546] Hardware name: BCM97278SV (DT)
[6.376649] Workqueue: events deferred_probe_work_func
[6.381796] pstate: 6005 (nZCv daif -PAN -UAO)
[6.386595] pc : refcount_inc_checked+0x38/0x44
[6.391133] lr : refcount_inc_checked+0x38/0x44
...
[6.478791] Call trace:
[6.481243] refcount_inc_checked+0x38/0x44
[6.485433] kobject_get+0x3c/0x4c
[6.488840] of_node_get+0x24/0x34
[6.492247] of_irq_find_parent+0x3c/0xe0
[6.496263] of_irq_parse_one+0xe4/0x1d0
[6.500191] irq_of_parse_and_map+0x44/0x84
[6.504381] bcm_sf2_sw_probe+0x22c/0x844
[6.508397] platform_drv_probe+0x58/0xa8
[6.512413] really_probe+0x238/0x3fc
[6.516081] driver_probe_device+0x11c/0x12c
[6.520358] __device_attach_driver+0xa8/0x100
[6.524808] bus_for_each_drv+0xb4/0xd0
[6.528650] __device_attach+0xd0/0x164
[6.532493] device_initial_probe+0x24/0x30
[6.536682] bus_probe_device+0x38/0x98
[6.540524] deferred_probe_work_func+0xa8/0xd4
[6.545061] process_one_work+0x178/0x288
[6.549078] process_scheduled_works+0x44/0x48
[6.553529] worker_thread+0x218/0x270
[6.557285] kthread+0xdc/0xe4
[6.560344] ret_from_fork+0x10/0x18
[6.563925] ---[ end trace 68f65caf69bb152a ]---
Fix this by adding a of_node_get() to increment the reference count
prior to the call.
Fixes: afa3b592953b ("net: dsa: bcm_sf2: Ensure correct sub-node is parsed")
Signed-off-by: Florian Fainelli
---
drivers/net/dsa/bcm_sf2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index c1bd21e4b15c..9f62ba3e4345 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1154,6 +1154,8 @@ static int bcm_sf2_sw_probe(struct platform_device *pdev)
set_bit(0, priv->cfp.used);
set_bit(0, priv->cfp.unique);
+ /* Balance of_node_put() done by of_find_node_by_name() */
+ of_node_get(dn);
ports = of_find_node_by_name(dn, "ports");
if (ports) {
bcm_sf2_identify_ports(priv, ports);
--
2.17.1
Re: [PATCH v8 11/14] media: dt-bindings: Add jpeg enc device tree node document
On Thu, 2020-05-21 at 16:00 +, Tomasz Figa wrote:
> Hi Xia,
>
> On Fri, Apr 03, 2020 at 05:40:30PM +0800, Xia Jiang wrote:
> > Add jpeg enc device tree node document
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Xia Jiang
> > ---
> > v8: no changes
> >
> > v7: no changes
> >
> > v6: no changes
> >
> > v5: no changes
> >
> > v4: no changes
> >
> > v3: change compatible to SoC specific compatible
> >
> > v2: no changes
> > ---
> > .../bindings/media/mediatek-jpeg-encoder.txt | 37 +++
> > 1 file changed, 37 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> >
>
> Thank you for the patch. Please see my comments inline.
Dear Tomasz,
Sorry for missing this message. Replied below.
>
> > diff --git
> > a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > new file mode 100644
> > index ..fa8da699493b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt
> > @@ -0,0 +1,37 @@
> > +* MediaTek JPEG Encoder
> > +
> > +MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs
> > +
> > +Required properties:
> > +- compatible : should be one of:
> > + "mediatek,mt2701-jpgenc"
> > + ...
>
> What does this "..." mean?
"..." means that compatible name is not just "mediatek,mt2701-jpgenc",
different project has different compatible name(for example the MT8173's
compatible name may be "mediatek,mt8173-jpgenc").
>
> > + followed by "mediatek,mtk-jpgenc"
> > +- reg : physical base address of the JPEG encoder registers and length of
> > + memory mapped region.
> > +- interrupts : interrupt number to the interrupt controller.
> > +- clocks: device clocks, see
> > + Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> > +- clock-names: must contain "jpgenc". It is the clock of JPEG encoder.
>
> nit: In principle the clocks should be named after the function the clock
> performs on the consumer side, i.e. the JPEG block in this case, I guess
> here it's just a generic clock that does everything, but I guess it comes
> from somewhere. Is it the AHB clock or something? In that case it would
> normally be called "ahb".
I have confirmed with hardware designer that the jpeg clock is not AHB
clock,it follows subsys clock(because 2701 is the old IC,I didn't get
the source name).It has the same source with venc clock.We can see that
the clocks = , Should I name it "venc" or the
orignal "jpgenc"?
>
> > +- power-domains: a phandle to the power domain, see
> > + Documentation/devicetree/bindings/power/power_domain.txt for details.
> > +- mediatek,larb: must contain the local arbiters in the current SoCs, see
> > +
> > Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> > + for details.
>
> I believe this isn't necessary anymore, because larbs are added
> automatically by the MTK IOMMU driver using device links. +CC Yong who
> worked on that.
Yes,I have confirmed with Yong that he will help me to modify this.Is it
ok that I keep the orignal larb code?
Best Regards,
Xia Jiang
>
> > +- iommus: should point to the respective IOMMU block with master port as
> > + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
> > + for details.
> > +
> > +Example:
> > + jpegenc: jpegenc@1500a000 {
> > + compatible = "mediatek,mt2701-jpgenc",
> > +"mediatek,mtk-jpgenc";
> > + reg = <0 0x1500a000 0 0x1000>;
> > + interrupts = ;
> > + clocks = < CLK_IMG_VENC>;
> > + clock-names = "jpgenc";
> > + power-domains = < MT2701_POWER_DOMAIN_ISP>;
> > + mediatek,larb = <>;
>
> Ditto.
>
> Best regards,
> Tomasz
Re: [PATCH] [net/sched]: Remove redundant condition in qdisc_graft
On 6/17/20 6:23 PM, Gaurav Singh wrote: > Signed-off-by: Gaurav Singh Two Signed-off-by ? > > Fix build errors Your patch does not fix a build error. > > Signed-off-by: Gaurav Singh > --- > net/sched/sch_api.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c > index 9a3449b56bd6..be93ebcdb18d 100644 > --- a/net/sched/sch_api.c > +++ b/net/sched/sch_api.c > @@ -1094,7 +1094,7 @@ static int qdisc_graft(struct net_device *dev, struct > Qdisc *parent, > > /* Only support running class lockless if parent is lockless */ > if (new && (new->flags & TCQ_F_NOLOCK) && > - parent && !(parent->flags & TCQ_F_NOLOCK)) > + !(parent->flags & TCQ_F_NOLOCK)) > qdisc_clear_nolock(new); > > if (!cops || !cops->graft) >
Re: [f2fs-dev] [PATCH] f2fs: avoid checkpatch error
On 2020/6/17 3:02, Jaegeuk Kim wrote: > ERROR:INITIALISED_STATIC: do not initialise statics to NULL > > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu Thanks,
[PATCH V4 3/3] dt-bindings: clock: Correct example in i.MX8QXP LPCG binding
In i.MX8QXP LPCG binding's example, "fsl,imx7d-usdhc" as fallback
compatible is incorrect, remove it to avoid below build error:
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml:
mmc@5b01: compatible: Additional items are not allowed ('fsl,imx7d-usdhc'
was unexpected)
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.example.dt.yaml:
mmc@5b01: compatible: ['fsl,imx8qxp-usdhc', 'fsl,imx7d-usdhc'] is too long
Signed-off-by: Anson Huang
---
New patch, to fix build error when patch #1 is added.
---
Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
index 33f3010..1d5e9bc 100644
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -62,7 +62,7 @@ examples:
};
mmc@5b01 {
-compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+compatible = "fsl,imx8qxp-usdhc";
interrupts = ;
reg = <0x5b01 0x1>;
clocks = <_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
--
2.7.4
[PATCH V4 2/3] dt-bindings: clock: Correct mmc node name in i.MX35 binding
Nodename should be "mmc" instead of "esdhc" in i.MX35 clock binding
to avoid below build error:
Documentation/devicetree/bindings/clock/imx35-clock.example.dt.yaml:
esdhc@53fb4000: $nodename:0: 'esdhc@53fb4000' does not match '^mmc(@.*)?$'
Signed-off-by: Anson Huang
---
New patch, to fix build error when patch #1 is added.
---
Documentation/devicetree/bindings/clock/imx35-clock.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml
b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
index bd871da..3e20cca 100644
--- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml
@@ -130,7 +130,7 @@ examples:
#clock-cells = <1>;
};
-esdhc@53fb4000 {
+mmc@53fb4000 {
compatible = "fsl,imx35-esdhc";
reg = <0x53fb4000 0x4000>;
interrupts = <7>;
--
2.7.4
[PATCH V4 1/3] dt-bindings: mmc: Convert imx esdhc to json-schema
Convert the i.MX ESDHC binding to DT schema format using json-schema
Signed-off-by: Anson Huang
---
No change.
---
.../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 67 ---
.../devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 124 +
2 files changed, 124 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
deleted file mode 100644
index de1b8bd..000
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ /dev/null
@@ -1,67 +0,0 @@
-* Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
-
-The Enhanced Secure Digital Host Controller on Freescale i.MX family
-provides an interface for MMC, SD, and SDIO types of memory cards.
-
-This file documents differences between the core properties described
-by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
-
-Required properties:
-- compatible : Should be "fsl,-esdhc", the supported chips include
- "fsl,imx25-esdhc"
- "fsl,imx35-esdhc"
- "fsl,imx51-esdhc"
- "fsl,imx53-esdhc"
- "fsl,imx6q-usdhc"
- "fsl,imx6sl-usdhc"
- "fsl,imx6sx-usdhc"
- "fsl,imx6ull-usdhc"
- "fsl,imx7d-usdhc"
- "fsl,imx7ulp-usdhc"
- "fsl,imx8mq-usdhc"
- "fsl,imx8mm-usdhc"
- "fsl,imx8mn-usdhc"
- "fsl,imx8mp-usdhc"
- "fsl,imx8qm-usdhc"
- "fsl,imx8qxp-usdhc"
-
-Optional properties:
-- fsl,wp-controller : Indicate to use controller internal write protection
-- fsl,delay-line : Specify the number of delay cells for override mode.
- This is used to set the clock delay for DLL(Delay Line) on override mode
- to select a proper data sampling window in case the clock quality is not good
- due to signal path is too long on the board. Please refer to eSDHC/uSDHC
- chapter, DLL (Delay Line) section in RM for details.
-- voltage-ranges : Specify the voltage range in case there are software
- transparent level shifters on the outputs of the controller. Two cells are
- required, first cell specifies minimum slot voltage (mV), second cell
- specifies maximum slot voltage (mV). Several ranges could be specified.
-- fsl,tuning-start-tap: Specify the start dealy cell point when send first
CMD19
- in tuning procedure.
-- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
- The uSDHC use one delay cell as default increasing step to do tuning process.
- This property allows user to change the tuning step to more than one delay
- cells which is useful for some special boards or cards when the default
- tuning step can't find the proper delay window within limited tuning retries.
-- fsl,strobe-dll-delay-target: Specify the strobe dll control slave delay
target.
- This delay target programming host controller loopback read clock, and this
- property allows user to change the delay target for the strobe input read
clock.
- If not use this property, driver default set the delay target to value 7.
- Only eMMC HS400 mode need to take care of this property.
-
-Examples:
-
-esdhc@70004000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70004000 0x4000>;
- interrupts = <1>;
- fsl,wp-controller;
-};
-
-esdhc@70008000 {
- compatible = "fsl,imx51-esdhc";
- reg = <0x70008000 0x4000>;
- interrupts = <2>;
- cd-gpios = < 6 0>; /* GPIO1_6 */
- wp-gpios = < 5 0>; /* GPIO1_5 */
-};
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
new file mode 100644
index 000..75dc116
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/fsl-imx-esdhc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Enhanced Secure Digital Host Controller (eSDHC) for i.MX
+
+maintainers:
+ - Shawn Guo
+
+allOf:
+ - $ref: "mmc-controller.yaml"
+
+description: |
+ The Enhanced Secure Digital Host Controller on Freescale i.MX family
+ provides an interface for MMC, SD, and SDIO types of memory cards.
+
+ This file documents differences between the core properties described
+ by mmc.txt and the properties used by the sdhci-esdhc-imx driver.
+
+properties:
+ compatible:
+enum:
+ - fsl,imx25-esdhc
+ - fsl,imx35-esdhc
+ - fsl,imx51-esdhc
+ - fsl,imx53-esdhc
+ - fsl,imx6q-usdhc
+ - fsl,imx6sl-usdhc
+ - fsl,imx6sx-usdhc
+ - fsl,imx6ull-usdhc
+ - fsl,imx7d-usdhc
+ - fsl,imx7ulp-usdhc
+ - fsl,imx8mq-usdhc
+ -
Re: [PATCH v3] f2fs: use kfree() instead of kvfree() to free superblock data
On 2020/6/16 1:58, Jaegeuk Kim wrote:
> On 06/09, Eric Biggers wrote:
>> On Wed, Jun 10, 2020 at 01:14:46AM +0300, Denis Efremov wrote:
>>> Use kfree() instead of kvfree() to free super in read_raw_super_block()
>>> because the memory is allocated with kzalloc() in the function.
>>> Use kfree() instead of kvfree() to free sbi, raw_super in
>>> f2fs_fill_super() and f2fs_put_super() because the memory is allocated
>>> with kzalloc().
>>>
>>> Fixes: 5222595d093e ("f2fs: use kvmalloc, if kmalloc is failed")
>>> Signed-off-by: Denis Efremov
Reviewed-by: Chao Yu
Thanks,
>>
>> I don't think "Fixes" is appropriate here.
>
> Agreed. I queued this Cl without it. :)
> Thanks,
>
>>
>> kvfree() still works on kmalloc'ed memory; it's just not preferred.
>>
>> So this is more a cleanup than a fix.
>>
>> - Eric
> .
>
回复: 回复: [PATCH] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry
> On 2020/6/18 10:39, Zac wrote:
> >
> >> On 2020/6/17 17:04, zhaowu...@wingtech.com wrote:
> >>> From: Wuyun Zhao
> >>>
> >>> Under some condition, the __write_node_page will submit a page which
> is
> >> not
> >>> f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
> >>> f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read
the
> >> same node page
> >>> and set code node, which make f2fs_in_warm_node_list become true,
> >>> that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when
> >> f2fs_write_end_io called.
> >> Could you please add below race condition description into commit
> >> message?
> >>
> >> - f2fs_write_end_io
> >>- f2fs_iget
> >> - do_read_inode
> >> - set_cold_node
> >> recover cold node flag
> >> - f2fs_in_warm_node_list
> >> - is_cold_node
> >> if node is cold, assume we have added
> >> node to fsync_node_list during writepages()
> >> - f2fs_del_fsync_node_entry
> >> - f2fs_bug_on() due to node page
> >> is not in fsync_node_list
> >
> > Ok, will add the commit message.
> >
> >> BTW, I'm curious about why we can lose cold flag for non-dir inode?
> >> any clue to reproduce this bug (I mean losing cold flag)?
> >
> > it's a f2fs image with 25600MB
> > flash this image to device
> > the device will resize it according to the userdata partition size which
is
> > about 94GB
> > the device mount the f2fs partition
> > then hit this f2fs_bug_on
> >
> > seems that the cold flag is not been set when mkfs
>
> Ah, I guess both mkfs/sload ignores setting cold node flag for non-dir
inode,
> could you please send another patch to fix this issue?
Patch v2 has been sent.
> >
> > I think the issue is that
> >
> > 1. the node page in the storage is without cold bit
> > 2. f2fs_disable_checkpoint -> f2fs_gc -> f2fs_get_node_page, this page
> won't
> > be set cold flag
> > 3. f2fs_move_node_page -> __write_node_page to write this page
> > 4. f2fs_gc -> f2fs_iget -> do_read_inode to read this page and set cold
flag
>
> Clear enough, thanks for your explanation. :)
>
> Thanks,
>
> >
> >>>
> >>> [ 34.966133] Call trace:
> >>> [ 34.969902] f2fs_del_fsync_node_entry+0x100/0x108
> >>> [ 34.976071] f2fs_write_end_io+0x1e0/0x288
> >>> [ 34.981539] bio_endio+0x248/0x270
> >>> [ 34.986289] blk_update_request+0x2b0/0x4d8
> >>> [ 34.991841] scsi_end_request+0x40/0x440
> >>> [ 34.997126] scsi_io_completion+0xa4/0x748
> >>> [ 35.002593] scsi_finish_command+0xdc/0x110
> >>> [ 35.008143] scsi_softirq_done+0x118/0x150
> >>> [ 35.013610] blk_done_softirq+0x8c/0xe8
> >>> [ 35.018811] __do_softirq+0x2e8/0x578
> >>> [ 35.023828] irq_exit+0xfc/0x120
> >>> [ 35.028398] handle_IPI+0x1d8/0x330
> >>> [ 35.033233] gic_handle_irq+0x110/0x1d4
> >>> [ 35.038433] el1_irq+0xb4/0x130
> >>> [ 35.042917] kmem_cache_alloc+0x3f0/0x418
> >>> [ 35.048288] radix_tree_node_alloc+0x50/0xf8
> >>> [ 35.053933] __radix_tree_create+0xf8/0x188
> >>> [ 35.059484] __radix_tree_insert+0x3c/0x128
> >>> [ 35.065035] add_gc_inode+0x90/0x118
> >>> [ 35.069967] f2fs_gc+0x1b80/0x2d70
> >>> [ 35.074718] f2fs_disable_checkpoint+0x94/0x1d0
> >>> [ 35.080621] f2fs_fill_super+0x10c4/0x1b88
> >>> [ 35.086088] mount_bdev+0x194/0x1e0
> >>> [ 35.090923] f2fs_mount+0x40/0x50
> >>> [ 35.095589] mount_fs+0xb4/0x190
> >>> [ 35.100159] vfs_kern_mount+0x80/0x1d8
> >>> [ 35.105260] do_mount+0x478/0xf18
> >>> [ 35.109926] ksys_mount+0x90/0xd0
> >>> [ 35.114592] __arm64_sys_mount+0x24/0x38
> >>>
> >>> Signed-off-by: Wuyun Zhao
> >>
> >> Reviewed-by: Chao Yu
> >>
> >> Thanks,
> >>
> >>> ---
> >>> fs/f2fs/inode.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> >>> index be6ac33..0df5c8c 100644
> >>> --- a/fs/f2fs/inode.c
> >>> +++ b/fs/f2fs/inode.c
> >>> @@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
> >>>
> >>> /* try to recover cold bit for non-dir inode */
> >>> if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
> >>> + f2fs_wait_on_page_writeback(node_page, NODE, true, true);
> >>> set_cold_node(node_page, false);
> >>> set_page_dirty(node_page);
> >>> }
> >>>
> >
> > .
> >
[PATCH 1/2] spi: spidev: fix a race between spidev_release and spidev_remove
Imagine below scene, spidev is referenced after it's freed.
spidev_release()spidev_remove()
...
spin_lock_irq(>spi_lock);
spidev->spi = NULL;
spin_unlock_irq(>spi_lock);
mutex_lock(_list_lock);
dofree = (spidev->spi == NULL);
if (dofree)
kfree(spidev);
mutex_unlock(_list_lock);
mutex_lock(_list_lock);
list_del(>device_entry);
device_destroy(spidev_class, spidev->devt);
clear_bit(MINOR(spidev->devt), minors);
if (spidev->users == 0)
kfree(spidev);
mutex_unlock(_list_lock);
Fix it by resetting spidev->spi in device_list_lock's protection.
Signed-off-by: Zhenzhong Duan
---
drivers/spi/spidev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d753df7..f74ea26 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -787,13 +787,13 @@ static int spidev_remove(struct spi_device *spi)
{
struct spidev_data *spidev = spi_get_drvdata(spi);
+ /* prevent new opens */
+ mutex_lock(_list_lock);
/* make sure ops on existing fds can abort cleanly */
spin_lock_irq(>spi_lock);
spidev->spi = NULL;
spin_unlock_irq(>spi_lock);
- /* prevent new opens */
- mutex_lock(_list_lock);
list_del(>device_entry);
device_destroy(spidev_class, spidev->devt);
clear_bit(MINOR(spidev->devt), minors);
--
1.8.3.1
[PATCH 2/2] spi: spidev: fix a potential use-after-free in spidev_release()
If an spi device is unbounded from the driver before the release
process, there will be an NULL pointer reference when it's
referenced in spi_slave_abort().
Fix it by checking it's already freed before reference.
Signed-off-by: Zhenzhong Duan
---
drivers/spi/spidev.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index f74ea26..59e0767 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -609,15 +609,20 @@ static int spidev_open(struct inode *inode, struct file
*filp)
static int spidev_release(struct inode *inode, struct file *filp)
{
struct spidev_data *spidev;
+ int dofree;
mutex_lock(_list_lock);
spidev = filp->private_data;
filp->private_data = NULL;
+ spin_lock_irq(>spi_lock);
+ /* ... after we unbound from the underlying device? */
+ dofree = (spidev->spi == NULL);
+ spin_unlock_irq(>spi_lock);
+
/* last close? */
spidev->users--;
if (!spidev->users) {
- int dofree;
kfree(spidev->tx_buffer);
spidev->tx_buffer = NULL;
@@ -625,19 +630,14 @@ static int spidev_release(struct inode *inode, struct
file *filp)
kfree(spidev->rx_buffer);
spidev->rx_buffer = NULL;
- spin_lock_irq(>spi_lock);
- if (spidev->spi)
- spidev->speed_hz = spidev->spi->max_speed_hz;
-
- /* ... after we unbound from the underlying device? */
- dofree = (spidev->spi == NULL);
- spin_unlock_irq(>spi_lock);
-
if (dofree)
kfree(spidev);
+ else
+ spidev->speed_hz = spidev->spi->max_speed_hz;
}
#ifdef CONFIG_SPI_SLAVE
- spi_slave_abort(spidev->spi);
+ if (!dofree)
+ spi_slave_abort(spidev->spi);
#endif
mutex_unlock(_list_lock);
--
1.8.3.1
Re: [PATCH v2 09/16] rcu/tree: Maintain separate array for vmalloc ptrs
On Wed, Jun 17, 2020 at 05:52:14PM -0700, Matthew Wilcox wrote:
> On Wed, Jun 17, 2020 at 04:46:09PM -0700, Paul E. McKenney wrote:
> > > + // Handle two first channels.
> > > + for (i = 0; i < FREE_N_CHANNELS; i++) {
> > > + for (; bkvhead[i]; bkvhead[i] = bnext) {
> > > + bnext = bkvhead[i]->next;
> > > + debug_rcu_bhead_unqueue(bkvhead[i]);
> > > +
> > > + rcu_lock_acquire(_callback_map);
> > > + if (i == 0) { // kmalloc() / kfree().
> > > + trace_rcu_invoke_kfree_bulk_callback(
> > > + rcu_state.name, bkvhead[i]->nr_records,
> > > + bkvhead[i]->records);
> > > +
> > > + kfree_bulk(bkvhead[i]->nr_records,
> > > + bkvhead[i]->records);
> > > + } else { // vmalloc() / vfree().
> > > + for (j = 0; j < bkvhead[i]->nr_records; j++) {
> > > + trace_rcu_invoke_kfree_callback(
> > > + rcu_state.name,
> > > + bkvhead[i]->records[j], 0);
> > > +
> > > + vfree(bkvhead[i]->records[j]);
> > > + }
> > > + }
> > > + rcu_lock_release(_callback_map);
> >
> > Not an emergency, but did you look into replacing this "if" statement
> > with an array of pointers to functions implementing the legs of the
> > "if" statement? If nothing else, this would greatly reduced indentation.
>
> I don't think that replacing direct function calls with indirect function
> calls is a great suggestion with the current state of play around branch
> prediction.
>
> I'd suggest:
>
> rcu_lock_acquire(_callback_map);
> trace_rcu_invoke_kfree_bulk_callback(rcu_state.name,
> bkvhead[i]->nr_records, bkvhead[i]->records);
> if (i == 0) {
> kfree_bulk(bkvhead[i]->nr_records,
> bkvhead[i]->records);
> } else {
> for (j = 0; j < bkvhead[i]->nr_records; j++) {
> vfree(bkvhead[i]->records[j]);
> }
> }
> rcu_lock_release(_callback_map);
>
> But I'd also suggest a vfree_bulk be added. There are a few things
> which would be better done in bulk as part of the vfree process
> (we batch them up already, but i'm sure we could do better).
I suspect that he would like to keep the tracing.
It might be worth trying the branches, given that they would be constant
and indexed by "i". The compiler might well remove the indirection.
The compiler guys brag about doing so, which of course might or might
not have any correlation to a given compiler actually doing so. :-/
Having a vfree_bulk() might well be useful, but I would feel more
confidence in that if there were other callers of kfree_bulk().
But again, either way, future work as far as this series is concerned.
Thanx, Paul
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> -Original Message- > From: Aisheng Dong > Sent: 2020年6月18日 11:09 > To: Anson Huang ; li...@armlinux.org.uk; > shawn...@kernel.org; s.ha...@pengutronix.de; ker...@pengutronix.de; > feste...@gmail.com; mturque...@baylibre.com; sb...@kernel.org; > oleksandr.suvo...@toradex.com; Stefan Agner ; > a...@arndb.de; Abel Vesa ; Peng Fan > ; t...@linutronix.de; alli...@lohutok.net; > gre...@linuxfoundation.org; i...@metux.net; Leonard Crestez > ; Andy Duan ; Daniel > Baluta ; yuehaib...@huawei.com; > s...@canb.auug.org.au; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org > Cc: dl-linux-imx > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > From: Anson Huang > > Sent: Wednesday, June 17, 2020 8:36 PM > > > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > > > > > From: Anson Huang > > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > > > i.MX common clock drivers may support module build, so it is NOT > > > > selected by default, for ARCH_MXC ARMv7 platforms, need to select > > > > it manually to make build pass. > > > > > > > > Signed-off-by: Anson Huang > > > > > > Can't the original def_xxx work? > > > > > > config MXC_CLK > > > tristate > > > def_tristate ARCH_MXC > > > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers are > > selected as module, so it does NOT meet the requirement of module > > support. Below is from .config when all > > i.MX8 SoCs clock drivers are configured to module. > > > > CONFIG_MXC_CLK=y > > CONFIG_MXC_CLK_SCU=m > > CONFIG_CLK_IMX8MM=m > > CONFIG_CLK_IMX8MN=m > > CONFIG_CLK_IMX8MP=m > > CONFIG_CLK_IMX8MQ=m > > CONFIG_CLK_IMX8QXP=m > > > > It works at my side. > Below is my changes based on your patchset: > $ git diff > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index > 47b10d20f411..e7d7b90e2cf8 100644 > --- a/arch/arm/mach-imx/Kconfig > +++ b/arch/arm/mach-imx/Kconfig > @@ -4,7 +4,6 @@ menuconfig ARCH_MXC > depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || > ARM_SINGLE_ARMV7M > select ARCH_SUPPORTS_BIG_ENDIAN > select CLKSRC_IMX_GPT > - select MXC_CLK > select GENERIC_IRQ_CHIP > select GPIOLIB > select PINCTRL > diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index > 26cedbfe386c..f7b3e3a2cb9f 100644 > --- a/drivers/clk/imx/Kconfig > +++ b/drivers/clk/imx/Kconfig > @@ -3,6 +3,7 @@ > config MXC_CLK > tristate "IMX clock" > depends on ARCH_MXC > + def_tristate ARCH_MXC > > config MXC_CLK_SCU > tristate "IMX SCU clock" > I guess you tried imx_v6_v7_defconfig? It does NOT work for ARM64 defconfig when we try to make CONFIG_MXC_CLK=m, Below are my change, you can see in .config, even all i.MX8 SoCs clock drivers are configured to module, the CONFIG_MXC_CLK is still =y, but the expected result is =m. BTW, all i.MX8 SoCs select MXC_CLK in their kconfig, this patch just does the same thing for i.MX6/7 in common place. diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 47b10d2..e7d7b90 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -4,7 +4,6 @@ menuconfig ARCH_MXC depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M select ARCH_SUPPORTS_BIG_ENDIAN select CLKSRC_IMX_GPT - select MXC_CLK select GENERIC_IRQ_CHIP select GPIOLIB select PINCTRL diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 8222e4b..21e2dbb 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -799,11 +799,11 @@ CONFIG_COMMON_CLK_S2MPS11=y CONFIG_COMMON_CLK_PWM=y CONFIG_COMMON_CLK_VC5=y CONFIG_CLK_RASPBERRYPI=m -CONFIG_CLK_IMX8MM=y -CONFIG_CLK_IMX8MN=y -CONFIG_CLK_IMX8MP=y -CONFIG_CLK_IMX8MQ=y -CONFIG_CLK_IMX8QXP=y +CONFIG_CLK_IMX8MM=m +CONFIG_CLK_IMX8MN=m +CONFIG_CLK_IMX8MP=m +CONFIG_CLK_IMX8MQ=m +CONFIG_CLK_IMX8QXP=m CONFIG_TI_SCI_CLK=y CONFIG_COMMON_CLK_QCOM=y CONFIG_QCOM_A53PLL=y diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index 26cedbf..f7b3e3a 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -3,6 +3,7 @@ config MXC_CLK tristate "IMX clock" depends on ARCH_MXC + def_tristate ARCH_MXC config MXC_CLK_SCU tristate "IMX SCU clock" .config: CONFIG_MXC_CLK=y CONFIG_MXC_CLK_SCU=m CONFIG_CLK_IMX8MM=m CONFIG_CLK_IMX8MN=m CONFIG_CLK_IMX8MP=m CONFIG_CLK_IMX8MQ=m CONFIG_CLK_IMX8QXP=m Anson
Re: [PATCH v5 01/13] powerpc: Remove Xilinx PPC405/PPC440 support
On Thu, Jun 18, 2020 at 10:48:21AM +1000, Michael Ellerman wrote: > Nick Desaulniers writes: > > On Wed, Jun 17, 2020 at 3:20 AM Michael Ellerman > > wrote: > >> Michael Ellerman writes: > >> > Michal Simek writes: > >> > >> > >> >> Or if bamboo requires uImage to be built by default you can do it via > >> >> Kconfig. > >> >> > >> >> diff --git a/arch/powerpc/platforms/44x/Kconfig > >> >> b/arch/powerpc/platforms/44x/Kconfig > >> >> index 39e93d23fb38..300864d7b8c9 100644 > >> >> --- a/arch/powerpc/platforms/44x/Kconfig > >> >> +++ b/arch/powerpc/platforms/44x/Kconfig > >> >> @@ -13,6 +13,7 @@ config BAMBOO > >> >> select PPC44x_SIMPLE > >> >> select 440EP > >> >> select FORCE_PCI > >> >> + select DEFAULT_UIMAGE > >> >> help > >> >> This option enables support for the IBM PPC440EP evaluation > >> >> board. > >> > > >> > Who knows what the actual bamboo board used. But I'd be happy to take a > >> > SOB'ed patch to do the above, because these days the qemu emulation is > >> > much more likely to be used than the actual board. > >> > >> I just went to see why my CI boot of 44x didn't catch this, and it's > >> because I don't use the uImage, I just boot the vmlinux directly: > >> > >> $ qemu-system-ppc -M bamboo -m 128m -display none -kernel build~/vmlinux > >> -append "console=ttyS0" -display none -nodefaults -serial mon:stdio > >> Linux version 5.8.0-rc1-00118-g69119673bd50 (michael@alpine1-p1) (gcc > >> (Ubuntu 9.3.0-10ubuntu2) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #4 > >> Wed Jun 17 20:19:22 AEST 2020 > >> Using PowerPC 44x Platform machine description > >> ioremap() called early from find_legacy_serial_ports+0x690/0x770. Use > >> early_ioremap() instead > >> printk: bootconsole [udbg0] enabled > >> > >> > >> So that's probably the simplest solution? > > > > If the uImage or zImage self decompresses, I would prefer to test that as > > well. > > The uImage is decompressed by qemu AIUI. > > >> That means previously arch/powerpc/boot/zImage was just a hardlink to > >> the uImage: > > > > It sounds like we can just boot the zImage, or is that no longer > > created with the uImage? > > The zImage won't boot on bamboo. > > Because of the vagaries of the arch/powerpc/boot/Makefile the zImage > ends up pointing to treeImage.ebony, which is for a different board. > > The zImage link is made to the first item in $(image-y): > > $(obj)/zImage:$(addprefix $(obj)/, $(image-y)) > $(Q)rm -f $@; ln $< $@ > ^ > first preqrequisite > > Which for this defconfig happens to be: > > image-$(CONFIG_EBONY) += treeImage.ebony cuImage.ebony > > If you turned off CONFIG_EBONY then the zImage will be a link to > treeImage.bamboo, but qemu can't boot that either. > > It's kind of nuts that the zImage points to some arbitrary image > depending on what's configured and the order of things in the Makefile. > But I'm not sure how we make it less nuts without risking breaking > people's existing setups. > > cheers Hi Michael, For what it's worth, this is squared this away in terms of our CI by just building and booting the uImage directly, rather than implicitly using the zImage: https://github.com/ClangBuiltLinux/continuous-integration/pull/282 https://github.com/ClangBuiltLinux/boot-utils/pull/22 We were only using the zImage because that is what Joel Stanley intially set us up with when PowerPC 32-bit was added to our CI: https://github.com/ClangBuiltLinux/continuous-integration/pull/100 Admittedly, we really do not have many PowerPC experts in our organization so we are supporting it on a "best effort" basis, which often involves using whatever knowledge is floating around or can be gained from interactions such as this :) so thank you for that! Cheers, Nathan
RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC
> From: Anson Huang > Sent: Wednesday, June 17, 2020 8:36 PM > > > Subject: RE: [PATCH V2 2/9] ARM: imx: Select MXC_CLK for ARCH_MXC > > > > > From: Anson Huang > > > Sent: Tuesday, June 9, 2020 3:32 PM > > > > > > i.MX common clock drivers may support module build, so it is NOT > > > selected by default, for ARCH_MXC ARMv7 platforms, need to select it > > > manually to make build pass. > > > > > > Signed-off-by: Anson Huang > > > > Can't the original def_xxx work? > > > > config MXC_CLK > > tristate > > def_tristate ARCH_MXC > > Such change will make MXC_CLK=y even all i.MX8 SoCs clock drivers are selected > as module, so it does NOT meet the requirement of module support. Below is > from .config when all > i.MX8 SoCs clock drivers are configured to module. > > CONFIG_MXC_CLK=y > CONFIG_MXC_CLK_SCU=m > CONFIG_CLK_IMX8MM=m > CONFIG_CLK_IMX8MN=m > CONFIG_CLK_IMX8MP=m > CONFIG_CLK_IMX8MQ=m > CONFIG_CLK_IMX8QXP=m > It works at my side. Below is my changes based on your patchset: $ git diff diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index 47b10d20f411..e7d7b90e2cf8 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -4,7 +4,6 @@ menuconfig ARCH_MXC depends on ARCH_MULTI_V4_V5 || ARCH_MULTI_V6_V7 || ARM_SINGLE_ARMV7M select ARCH_SUPPORTS_BIG_ENDIAN select CLKSRC_IMX_GPT - select MXC_CLK select GENERIC_IRQ_CHIP select GPIOLIB select PINCTRL diff --git a/drivers/clk/imx/Kconfig b/drivers/clk/imx/Kconfig index 26cedbfe386c..f7b3e3a2cb9f 100644 --- a/drivers/clk/imx/Kconfig +++ b/drivers/clk/imx/Kconfig @@ -3,6 +3,7 @@ config MXC_CLK tristate "IMX clock" depends on ARCH_MXC + def_tristate ARCH_MXC config MXC_CLK_SCU tristate "IMX SCU clock" Regards Aisheng > Anson
[tip:x86/misc] BUILD SUCCESS 5603119e48d0fee163a827c2342b372f1a0e913c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/misc branch HEAD: 5603119e48d0fee163a827c2342b372f1a0e913c x86/msr: Filter MSR writes elapsed time: 720m configs tested: 100 configs skipped: 93 The following configs have been built successfully. More configs may be tested in the coming days. arm64allyesconfig arm64 defconfig arm64allmodconfig arm64 allnoconfig arm defconfig arm allyesconfig arm allmodconfig arm allnoconfig c6x alldefconfig xtensa defconfig riscv rv32_defconfig i386 allnoconfig i386 allyesconfig i386defconfig i386 debian-10.3 ia64 allmodconfig ia64defconfig ia64 allnoconfig ia64 allyesconfig m68k allmodconfig m68k allnoconfig m68k sun3_defconfig m68kdefconfig m68k allyesconfig nios2 defconfig nios2allyesconfig openriscdefconfig c6x allyesconfig c6x allnoconfig openrisc allyesconfig nds32 defconfig nds32 allnoconfig csky allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig h8300allmodconfig arc defconfig arc allyesconfig sh allmodconfig shallnoconfig microblazeallnoconfig mips allyesconfig mips allnoconfig mips allmodconfig pariscallnoconfig parisc defconfig parisc allyesconfig parisc allmodconfig powerpc defconfig powerpc allyesconfig powerpc rhel-kconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a006-20200617 i386 randconfig-a002-20200617 i386 randconfig-a001-20200617 i386 randconfig-a004-20200617 i386 randconfig-a005-20200617 i386 randconfig-a003-20200617 x86_64 randconfig-a015-20200617 x86_64 randconfig-a011-20200617 x86_64 randconfig-a016-20200617 x86_64 randconfig-a014-20200617 x86_64 randconfig-a012-20200617 x86_64 randconfig-a013-20200617 i386 randconfig-a015-20200617 i386 randconfig-a011-20200617 i386 randconfig-a014-20200617 i386 randconfig-a016-20200617 i386 randconfig-a013-20200617 i386 randconfig-a012-20200617 riscvallyesconfig riscv allnoconfig riscv defconfig riscvallmodconfig s390 allyesconfig s390 allnoconfig s390 allmodconfig s390defconfig sparcallyesconfig sparc defconfig sparc64 defconfig sparc64 allnoconfig sparc64 allyesconfig sparc64 allmodconfig um allmodconfig umallnoconfig um allyesconfig um defconfig x86_64 rhel-7.6 x86_64rhel-7.6-kselftests x86_64 rhel-8.3 x86_64 kexec x86_64 rhel x86_64 rhel-7.2-clear x86_64lkp x86_64 fedora-25 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01
Re: [PATCH v5 09/12] PCI: brcmstb: Set internal memory viewport sizes
On Wed, Jun 17, 2020 at 01:28:12PM -0400, Jim Quinlan wrote:
> Hello Bjorn,
>
> On Tue, Jun 16, 2020 at 6:05 PM Bjorn Helgaas wrote:
> >
> > On Tue, Jun 16, 2020 at 04:55:16PM -0400, Jim Quinlan wrote:
> > > BrcmSTB PCIe controllers are intimately connected to the memory
> > > controller(s) on the SOC. There is a "viewport" for each memory
> > > controller
> > > that allows inbound accesses to CPU memory. Each viewport's size must be
> > > set to a power of two, and that size must be equal to or larger than the
> > > amount of memory each controller supports.
> >
> > This describes some requirements, but doesn't actually say what this
> > patch *does*.
> >
> > I *think* it reads the viewport sizes from the "brcm,scb-sizes" DT
> > property instead of computing something from "dma-ranges". Looks like
> > it also adds support for SCB1 and SCB2.
> >
> > Those seem interesting, but don't really come through in the subject
> > or even the commit log.
> >
> > If I understand correctly, this is all for DMA ("inbound accesses to
> > CPU memory"). I think it would be worth mentioning "DMA", since
> > that's the common term for this.
>
>
> I have changed the commit message to the text below. Please let me
> know if it requires more work
> Thanks, Jim
>
> PCI: brcmstb: Set internal memory DMA viewport sizes
Did you not set the viewport sizes before?
> BrcmSTB PCIe controllers are intimately connected to the memory
> controller(s) on the SOC. There is a "viewport" for each memory controller
> that allows inbound DMA acceses to CPU memory. Each viewport's size must
> be set to a power of two, and that size must be equal to or larger than the
> amount of memory each controller supports. Unfortunately the viewport
> sizes cannot be ascertained from the "dma-ranges" property so they have
> their own property, "brcm,scb-sizes".
s/inbound DMA acceses to CPU memory/DMA/
"Accesses" is redundant since the "A" in "DMA" stands for "access".
I'm not sure "inbound" adds anything and might confuse since DMA may
be either a read or write of CPU memory.
I assume *all* drivers need to know the address and size of regions in
"dma-ranges". Is there something special about this device that means
it needs something different?
I guess it's the base/extension split? That couldn't be described as
two separate DMA ranges?
Could/should the new property have a name somehow related to
"dma-ranges"?
Should "dma-ranges" be documented in
Documentation/devicetree/bindings/pci/pci.txt instead of the
individual device bindings?
> There may be one to three memory controllers; they are indicated by the
> term SCBi. Each controller has a base region and an optional extension
> region. In physical memory, the base and extension regions are not
> adjacent, but in PCIe-space they are. Further, the 1-3 viewports are also
> adjacent in PCIe-space.
>
> The SCB settings work in conjunction with the "dma-ranges' offsets to
> enable non-identity mappings between system memory and PCIe space.
s/ranges'/ranges"/ (mismatched quotes)
This describes the hardware, but still doesn't actually say what this
patch *does*.
If I'm a user, why do I want this patch? Does it fix something that
didn't work before? Does it increase the amount of DMA-able memory?
What does this mean in terms of backwards compatibility with old DTs?
Does this work with old DTs that don't have "brcm,scb-sizes"? Maybe
this is all related to specific devices that weren't supported before,
so there *are* no old DTs for them? I can't tell from the binding
update or the patch that this is related to specific devices.
> > > Signed-off-by: Jim Quinlan
> > > Acked-by: Florian Fainelli
> > > ---
> > > drivers/pci/controller/pcie-brcmstb.c | 68 ---
> > > 1 file changed, 50 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/pcie-brcmstb.c
> > > b/drivers/pci/controller/pcie-brcmstb.c
> > > index 9189406fd35c..39f77709c6a2 100644
> > > --- a/drivers/pci/controller/pcie-brcmstb.c
> > > +++ b/drivers/pci/controller/pcie-brcmstb.c
> > > @@ -57,6 +57,8 @@
> > > #define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x30
> > > #define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
> > > #define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf800
> > > +#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c0
> > > +#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x001f
> > >
> > > #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
> > > #define PCIE_MEM_WIN0_LO(win)\
> > > @@ -154,6 +156,7 @@
> > > #define SSC_STATUS_OFFSET0x1
> > > #define SSC_STATUS_SSC_MASK 0x400
> > > #define SSC_STATUS_PLL_LOCK_MASK 0x800
> > > +#define PCIE_BRCM_MAX_MEMC 3
> > >
> > > #define IDX_ADDR(pcie)
> > > (pcie->reg_offsets[EXT_CFG_INDEX])
> > > #define DATA_ADDR(pcie)
> > >
[PATCH] [v2] pinctrl: meson: fix drive strength register and bit calculation
If a GPIO bank has greater than 16 pins, PAD_DS_REG is split into two
or more registers. However, when register and bit were calculated, the
first register defined in the bank was used, and the bit was calculated
based on the first pin. This causes problems in setting the driving
strength.
The following method was used to solve this problem:
A bit is calculated first using predefined strides. Then, If the bit is
32 or more, the register is changed by the quotient of the bit divided
by 32. And the bit is set to the remainder.
Signed-off-by: Hyeonki Hong
---
drivers/pinctrl/meson/pinctrl-meson.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c
b/drivers/pinctrl/meson/pinctrl-meson.c
index bbc919bef2bf..bf116c2e45c0 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -56,6 +56,10 @@
#include "../pinctrl-utils.h"
#include "pinctrl-meson.h"
+static const unsigned int meson_bit_strides[] = {
+ 1, 1, 1, 1, 1, 2, 1
+};
+
/**
* meson_get_bank() - find the bank containing a given pin
*
@@ -96,8 +100,9 @@ static void meson_calc_reg_and_bit(struct meson_bank *bank,
unsigned int pin,
{
struct meson_reg_desc *desc = >regs[reg_type];
- *reg = desc->reg * 4;
- *bit = desc->bit + pin - bank->first;
+ *bit = (desc->bit + pin - bank->first) * meson_bit_strides[reg_type];
+ *reg = (desc->reg + (*bit / 32)) * 4;
+ *bit &= 0x1f;
}
static int meson_get_groups_count(struct pinctrl_dev *pcdev)
@@ -314,7 +319,6 @@ static int meson_pinconf_set_drive_strength(struct
meson_pinctrl *pc,
return ret;
meson_calc_reg_and_bit(bank, pin, REG_DS, , );
- bit = bit << 1;
if (drive_strength_ua <= 500) {
ds_val = MESON_PINCONF_DRV_500UA;
@@ -441,7 +445,6 @@ static int meson_pinconf_get_drive_strength(struct
meson_pinctrl *pc,
return ret;
meson_calc_reg_and_bit(bank, pin, REG_DS, , );
- bit = bit << 1;
ret = regmap_read(pc->reg_ds, reg, );
if (ret)
--
2.17.1
[PATCH v2] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry
From: Wuyun Zhao
Under some condition, the __write_node_page will submit a page which is not
f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read the same
node page
and set code node, which make f2fs_in_warm_node_list become true,
that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when f2fs_write_end_io
called.
- f2fs_write_end_io
- f2fs_iget
- do_read_inode
- set_cold_node
recover cold node flag
- f2fs_in_warm_node_list
- is_cold_node
if node is cold, assume we have added
node to fsync_node_list during writepages()
- f2fs_del_fsync_node_entry
- f2fs_bug_on() due to node page
is not in fsync_node_list
[ 34.966133] Call trace:
[ 34.969902] f2fs_del_fsync_node_entry+0x100/0x108
[ 34.976071] f2fs_write_end_io+0x1e0/0x288
[ 34.981539] bio_endio+0x248/0x270
[ 34.986289] blk_update_request+0x2b0/0x4d8
[ 34.991841] scsi_end_request+0x40/0x440
[ 34.997126] scsi_io_completion+0xa4/0x748
[ 35.002593] scsi_finish_command+0xdc/0x110
[ 35.008143] scsi_softirq_done+0x118/0x150
[ 35.013610] blk_done_softirq+0x8c/0xe8
[ 35.018811] __do_softirq+0x2e8/0x578
[ 35.023828] irq_exit+0xfc/0x120
[ 35.028398] handle_IPI+0x1d8/0x330
[ 35.033233] gic_handle_irq+0x110/0x1d4
[ 35.038433] el1_irq+0xb4/0x130
[ 35.042917] kmem_cache_alloc+0x3f0/0x418
[ 35.048288] radix_tree_node_alloc+0x50/0xf8
[ 35.053933] __radix_tree_create+0xf8/0x188
[ 35.059484] __radix_tree_insert+0x3c/0x128
[ 35.065035] add_gc_inode+0x90/0x118
[ 35.069967] f2fs_gc+0x1b80/0x2d70
[ 35.074718] f2fs_disable_checkpoint+0x94/0x1d0
[ 35.080621] f2fs_fill_super+0x10c4/0x1b88
[ 35.086088] mount_bdev+0x194/0x1e0
[ 35.090923] f2fs_mount+0x40/0x50
[ 35.095589] mount_fs+0xb4/0x190
[ 35.100159] vfs_kern_mount+0x80/0x1d8
[ 35.105260] do_mount+0x478/0xf18
[ 35.109926] ksys_mount+0x90/0xd0
[ 35.114592] __arm64_sys_mount+0x24/0x38
Signed-off-by: Wuyun Zhao
Reviewed-by: Chao Yu
---
fs/f2fs/inode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index be6ac33..0df5c8c 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
/* try to recover cold bit for non-dir inode */
if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
+ f2fs_wait_on_page_writeback(node_page, NODE, true, true);
set_cold_node(node_page, false);
set_page_dirty(node_page);
}
--
2.7.4
Re: 回复: [PATCH] f2fs: fix a race condition between f2fs_write_end_io and f2fs_del_fsync_node_entry
On 2020/6/18 10:39, Zac wrote:
>
>> On 2020/6/17 17:04, zhaowu...@wingtech.com wrote:
>>> From: Wuyun Zhao
>>>
>>> Under some condition, the __write_node_page will submit a page which is
>> not
>>> f2fs_in_warm_node_list and will not call f2fs_add_fsync_node_entry.
>>> f2fs_gc continue to run to invoke f2fs_iget -> do_read_inode to read the
>> same node page
>>> and set code node, which make f2fs_in_warm_node_list become true,
>>> that will cause f2fs_bug_on in f2fs_del_fsync_node_entry when
>> f2fs_write_end_io called.
>> Could you please add below race condition description into commit
>> message?
>>
>> - f2fs_write_end_io
>> - f2fs_iget
>> - do_read_inode
>>- set_cold_node
>>recover cold node flag
>> - f2fs_in_warm_node_list
>> - is_cold_node
>> if node is cold, assume we have added
>> node to fsync_node_list during writepages()
>> - f2fs_del_fsync_node_entry
>> - f2fs_bug_on() due to node page
>> is not in fsync_node_list
>
> Ok, will add the commit message.
>
>> BTW, I'm curious about why we can lose cold flag for non-dir inode?
>> any clue to reproduce this bug (I mean losing cold flag)?
>
> it's a f2fs image with 25600MB
> flash this image to device
> the device will resize it according to the userdata partition size which is
> about 94GB
> the device mount the f2fs partition
> then hit this f2fs_bug_on
>
> seems that the cold flag is not been set when mkfs
Ah, I guess both mkfs/sload ignores setting cold node flag for non-dir inode,
could you please send another patch to fix this issue?
>
> I think the issue is that
>
> 1. the node page in the storage is without cold bit
> 2. f2fs_disable_checkpoint -> f2fs_gc -> f2fs_get_node_page, this page won't
> be set cold flag
> 3. f2fs_move_node_page -> __write_node_page to write this page
> 4. f2fs_gc -> f2fs_iget -> do_read_inode to read this page and set cold flag
Clear enough, thanks for your explanation. :)
Thanks,
>
>>>
>>> [ 34.966133] Call trace:
>>> [ 34.969902] f2fs_del_fsync_node_entry+0x100/0x108
>>> [ 34.976071] f2fs_write_end_io+0x1e0/0x288
>>> [ 34.981539] bio_endio+0x248/0x270
>>> [ 34.986289] blk_update_request+0x2b0/0x4d8
>>> [ 34.991841] scsi_end_request+0x40/0x440
>>> [ 34.997126] scsi_io_completion+0xa4/0x748
>>> [ 35.002593] scsi_finish_command+0xdc/0x110
>>> [ 35.008143] scsi_softirq_done+0x118/0x150
>>> [ 35.013610] blk_done_softirq+0x8c/0xe8
>>> [ 35.018811] __do_softirq+0x2e8/0x578
>>> [ 35.023828] irq_exit+0xfc/0x120
>>> [ 35.028398] handle_IPI+0x1d8/0x330
>>> [ 35.033233] gic_handle_irq+0x110/0x1d4
>>> [ 35.038433] el1_irq+0xb4/0x130
>>> [ 35.042917] kmem_cache_alloc+0x3f0/0x418
>>> [ 35.048288] radix_tree_node_alloc+0x50/0xf8
>>> [ 35.053933] __radix_tree_create+0xf8/0x188
>>> [ 35.059484] __radix_tree_insert+0x3c/0x128
>>> [ 35.065035] add_gc_inode+0x90/0x118
>>> [ 35.069967] f2fs_gc+0x1b80/0x2d70
>>> [ 35.074718] f2fs_disable_checkpoint+0x94/0x1d0
>>> [ 35.080621] f2fs_fill_super+0x10c4/0x1b88
>>> [ 35.086088] mount_bdev+0x194/0x1e0
>>> [ 35.090923] f2fs_mount+0x40/0x50
>>> [ 35.095589] mount_fs+0xb4/0x190
>>> [ 35.100159] vfs_kern_mount+0x80/0x1d8
>>> [ 35.105260] do_mount+0x478/0xf18
>>> [ 35.109926] ksys_mount+0x90/0xd0
>>> [ 35.114592] __arm64_sys_mount+0x24/0x38
>>>
>>> Signed-off-by: Wuyun Zhao
>>
>> Reviewed-by: Chao Yu
>>
>> Thanks,
>>
>>> ---
>>> fs/f2fs/inode.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
>>> index be6ac33..0df5c8c 100644
>>> --- a/fs/f2fs/inode.c
>>> +++ b/fs/f2fs/inode.c
>>> @@ -402,6 +402,7 @@ static int do_read_inode(struct inode *inode)
>>>
>>> /* try to recover cold bit for non-dir inode */
>>> if (!S_ISDIR(inode->i_mode) && !is_cold_node(node_page)) {
>>> + f2fs_wait_on_page_writeback(node_page, NODE, true, true);
>>> set_cold_node(node_page, false);
>>> set_page_dirty(node_page);
>>> }
>>>
>
> .
>
[PATCH AUTOSEL 5.7 012/388] staging: wfx: check ssidlen and prevent an array overflow
From: Dan Carpenter
[ Upstream commit 87f86cddda65cab8a7e3df8a00e16abeccaa0730 ]
We need to cap "ssidlen" to prevent a memcpy() overflow.
Fixes: 40115bbc40e2 ("staging: wfx: implement the rest of mac80211 API")
Signed-off-by: Dan Carpenter
Reviewed-by: Jérôme Pouiller
Link: https://lore.kernel.org/r/20200424104235.GA416402@mwanda
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/wfx/sta.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wfx/sta.c b/drivers/staging/wfx/sta.c
index 9d430346a58b..969d7a4a7fbd 100644
--- a/drivers/staging/wfx/sta.c
+++ b/drivers/staging/wfx/sta.c
@@ -520,7 +520,9 @@ static void wfx_do_join(struct wfx_vif *wvif)
ssidie = ieee80211_bss_get_ie(bss, WLAN_EID_SSID);
if (ssidie) {
ssidlen = ssidie[1];
- memcpy(ssid, [2], ssidie[1]);
+ if (ssidlen > IEEE80211_MAX_SSID_LEN)
+ ssidlen = IEEE80211_MAX_SSID_LEN;
+ memcpy(ssid, [2], ssidlen);
}
rcu_read_unlock();
--
2.25.1
[PATCH AUTOSEL 5.7 007/388] ASoC: SOF: imx8: Fix randbuild error
From: YueHaibing
[ Upstream commit fe17e6cdc0fefca96ba9659be4b2b07487cbf0c5 ]
when do randconfig like this:
CONFIG_SND_SOC_SOF_IMX8_SUPPORT=y
CONFIG_SND_SOC_SOF_IMX8=y
CONFIG_SND_SOC_SOF_OF=y
CONFIG_IMX_DSP=m
CONFIG_IMX_SCU=y
there is a link error:
sound/soc/sof/imx/imx8.o: In function 'imx8_send_msg':
imx8.c:(.text+0x380): undefined reference to 'imx_dsp_ring_doorbell'
Select IMX_DSP in SND_SOC_SOF_IMX8_SUPPORT to fix this
Fixes: f9ad75468453 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF
dependency")
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
Signed-off-by: Daniel Baluta
Link: https://lore.kernel.org/r/20200409071832.2039-2-daniel.bal...@oss.nxp.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
---
sound/soc/sof/imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
index bae4f7bf5f75..812749064ca8 100644
--- a/sound/soc/sof/imx/Kconfig
+++ b/sound/soc/sof/imx/Kconfig
@@ -14,7 +14,7 @@ if SND_SOC_SOF_IMX_TOPLEVEL
config SND_SOC_SOF_IMX8_SUPPORT
bool "SOF support for i.MX8"
depends on IMX_SCU
- depends on IMX_DSP
+ select IMX_DSP
help
This adds support for Sound Open Firmware for NXP i.MX8 platforms
Say Y if you have such a device.
--
2.25.1
Re: [PATCH] tools/thermal: tmon: include pthread and time headers in tmon.h
On 6/17/2020 4:58 PM, Markus Mayer wrote: > Include sys/time.h and pthread.h in tmon.h, so that types > "pthread_mutex_t" and "struct timeval tv" are known when tmon.h > references them. > > Without these headers, compiling tmon against musl-libc will fail with > these errors: > > In file included from sysfs.c:31:0: > tmon.h:47:8: error: unknown type name 'pthread_mutex_t' > extern pthread_mutex_t input_lock; > ^~~ > make[3]: *** [: sysfs.o] Error 1 > make[3]: *** Waiting for unfinished jobs > In file included from tui.c:31:0: > tmon.h:54:17: error: field 'tv' has incomplete type > struct timeval tv; > ^~ > make[3]: *** [: tui.o] Error 1 > make[2]: *** [Makefile:83: tmon] Error 2 > > Signed-off-by: Markus Mayer Acked-by: Florian Fainelli -- Florian
[PATCH AUTOSEL 5.7 006/388] i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets
From: Adam Honse
[ Upstream commit f27237c174fd965300e4e532cd9d153ce824 ]
The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper
equivalents have a secondary SMBus controller at I/O port address
0x0B20. This bus is used by several manufacturers to control
motherboard RGB lighting via embedded controllers. I have been using
this bus in my OpenRGB project to control the Aura RGB on many
motherboards and ASRock also uses this bus for their Polychrome RGB
controller.
I am not aware of any CZ-compatible platforms which do not have the
second SMBus channel. All of AMD's AM4- and Threadripper- series
chipsets that OpenRGB users have tested appear to have this secondary
bus. I also noticed this secondary bus is present on older AMD
platforms including my FM1 home server.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587
Signed-off-by: Adam Honse
Reviewed-by: Jean Delvare
Reviewed-by: Sebastian Reichel
Tested-by: Sebastian Reichel
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
---
drivers/i2c/busses/i2c-piix4.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 30ded6422e7b..69740a4ff1db 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -977,7 +977,8 @@ static int piix4_probe(struct pci_dev *dev, const struct
pci_device_id *id)
}
if (dev->vendor == PCI_VENDOR_ID_AMD &&
- dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) {
+ (dev->device == PCI_DEVICE_ID_AMD_HUDSON2_SMBUS ||
+dev->device == PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)) {
retval = piix4_setup_sb800(dev, id, 1);
}
--
2.25.1
[PATCH AUTOSEL 5.7 011/388] clk: qcom: msm8916: Fix the address location of pll->config_reg
From: Bryan O'Donoghue
[ Upstream commit f47ab3c2f5338828a67e89d5f688d2cef9605245 ]
During the process of debugging a processor derived from the msm8916 which
we found the new processor was not starting one of its PLLs.
After tracing the addresses and writes that downstream was doing and
comparing to upstream it became obvious that we were writing to a different
register location than downstream when trying to configure the PLL.
This error is also present in upstream msm8916.
As an example clk-pll.c::clk_pll_recalc_rate wants to write to
pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is
defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an
example
lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf
0x01823010 GCC_BIMC_PLL_USER_CTL
0x01823014 GCC_BIMC_PLL_CONFIG_CTL
This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll.
This error is likely not apparent since the bootloader will already have
initialized these PLLs.
This patch corrects the location of config_reg from PLL_CONFIG_CTL to
PLL_USER_CTL for all relevant PLLs on msm8916.
Fixes commit 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller
support")
Cc: Georgi Djakov
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: Michael Turquette
Cc: Stephen Boyd
Signed-off-by: Bryan O'Donoghue
Link:
https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonog...@linaro.org
Signed-off-by: Stephen Boyd
Signed-off-by: Sasha Levin
---
drivers/clk/qcom/gcc-msm8916.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index 4e329a7baf2b..17e4a5a2a9fd 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -260,7 +260,7 @@ static struct clk_pll gpll0 = {
.l_reg = 0x21004,
.m_reg = 0x21008,
.n_reg = 0x2100c,
- .config_reg = 0x21014,
+ .config_reg = 0x21010,
.mode_reg = 0x21000,
.status_reg = 0x2101c,
.status_bit = 17,
@@ -287,7 +287,7 @@ static struct clk_pll gpll1 = {
.l_reg = 0x20004,
.m_reg = 0x20008,
.n_reg = 0x2000c,
- .config_reg = 0x20014,
+ .config_reg = 0x20010,
.mode_reg = 0x2,
.status_reg = 0x2001c,
.status_bit = 17,
@@ -314,7 +314,7 @@ static struct clk_pll gpll2 = {
.l_reg = 0x4a004,
.m_reg = 0x4a008,
.n_reg = 0x4a00c,
- .config_reg = 0x4a014,
+ .config_reg = 0x4a010,
.mode_reg = 0x4a000,
.status_reg = 0x4a01c,
.status_bit = 17,
@@ -341,7 +341,7 @@ static struct clk_pll bimc_pll = {
.l_reg = 0x23004,
.m_reg = 0x23008,
.n_reg = 0x2300c,
- .config_reg = 0x23014,
+ .config_reg = 0x23010,
.mode_reg = 0x23000,
.status_reg = 0x2301c,
.status_bit = 17,
--
2.25.1
[Linux] [PATCH] Kernel selftests: tpm2: upgrade tpm2 tests from python2 to python3
Some Linux OS will never support python2 anymore, so upgrade tpm2 selftests to python3. Signed-off-by: Pengfei Xu --- tools/testing/selftests/tpm2/test_smoke.sh | 4 +- tools/testing/selftests/tpm2/test_space.sh | 2 +- tools/testing/selftests/tpm2/tpm2.py | 68 ++ tools/testing/selftests/tpm2/tpm2_tests.py | 24 +--- 4 files changed, 61 insertions(+), 37 deletions(-) diff --git a/tools/testing/selftests/tpm2/test_smoke.sh b/tools/testing/selftests/tpm2/test_smoke.sh index 663062701d5a..d05467f6d258 100755 --- a/tools/testing/selftests/tpm2/test_smoke.sh +++ b/tools/testing/selftests/tpm2/test_smoke.sh @@ -6,8 +6,8 @@ ksft_skip=4 [ -f /dev/tpm0 ] || exit $ksft_skip -python -m unittest -v tpm2_tests.SmokeTest -python -m unittest -v tpm2_tests.AsyncTest +python3 -m unittest -v tpm2_tests.SmokeTest +python3 -m unittest -v tpm2_tests.AsyncTest CLEAR_CMD=$(which tpm2_clear) if [ -n $CLEAR_CMD ]; then diff --git a/tools/testing/selftests/tpm2/test_space.sh b/tools/testing/selftests/tpm2/test_space.sh index 36c9d030a1c6..151c64e8ee9f 100755 --- a/tools/testing/selftests/tpm2/test_space.sh +++ b/tools/testing/selftests/tpm2/test_space.sh @@ -6,4 +6,4 @@ ksft_skip=4 [ -f /dev/tpmrm0 ] || exit $ksft_skip -python -m unittest -v tpm2_tests.SpaceTest +python3 -m unittest -v tpm2_tests.SpaceTest diff --git a/tools/testing/selftests/tpm2/tpm2.py b/tools/testing/selftests/tpm2/tpm2.py index d0fcb66a88a6..b0ccc1499c53 100644 --- a/tools/testing/selftests/tpm2/tpm2.py +++ b/tools/testing/selftests/tpm2/tpm2.py @@ -247,14 +247,18 @@ class ProtocolError(Exception): class AuthCommand(object): """TPMS_AUTH_COMMAND""" -def __init__(self, session_handle=TPM2_RS_PW, nonce='', session_attributes=0, - hmac=''): +def __init__(self, session_handle=TPM2_RS_PW, nonce=''.encode(), + session_attributes=0, hmac=''.encode()): +if not isinstance(nonce, bytes): +nonce = nonce.encode() +if not isinstance(hmac, bytes): +hmac = hmac.encode() self.session_handle = session_handle self.nonce = nonce self.session_attributes = session_attributes self.hmac = hmac -def __str__(self): +def __bytes__(self): fmt = '>I H%us B H%us' % (len(self.nonce), len(self.hmac)) return struct.pack(fmt, self.session_handle, len(self.nonce), self.nonce, self.session_attributes, len(self.hmac), @@ -268,11 +272,15 @@ class AuthCommand(object): class SensitiveCreate(object): """TPMS_SENSITIVE_CREATE""" -def __init__(self, user_auth='', data=''): +def __init__(self, user_auth=''.encode(), data=''.encode()): +if not isinstance(user_auth, bytes): +user_auth = user_auth.encode() +if not isinstance(data, bytes): +data = data.encode() self.user_auth = user_auth self.data = data -def __str__(self): +def __bytes__(self): fmt = '>H%us H%us' % (len(self.user_auth), len(self.data)) return struct.pack(fmt, len(self.user_auth), self.user_auth, len(self.data), self.data) @@ -296,8 +304,15 @@ class Public(object): return '>HHIH%us%usH%us' % \ (len(self.auth_policy), len(self.parameters), len(self.unique)) -def __init__(self, object_type, name_alg, object_attributes, auth_policy='', - parameters='', unique=''): +def __init__(self, object_type, name_alg, object_attributes, + auth_policy=''.encode(), parameters=''.encode(), + unique=''.encode()): +if not isinstance(auth_policy, bytes): +auth_policy = auth_policy.encode() +if not isinstance(parameters, bytes): +parameters = parameters.encode() +if not isinstance(unique, bytes): +unique = unique.encode() self.object_type = object_type self.name_alg = name_alg self.object_attributes = object_attributes @@ -305,7 +320,7 @@ class Public(object): self.parameters = parameters self.unique = unique -def __str__(self): +def __bytes__(self): return struct.pack(self.__fmt(), self.object_type, self.name_alg, @@ -343,7 +358,7 @@ def get_algorithm(name): def hex_dump(d): d = [format(ord(x), '02x') for x in d] -d = [d[i: i + 16] for i in xrange(0, len(d), 16)] +d = [d[i: i + 16] for i in range(0, len(d), 16)] d = [' '.join(x) for x in d] d = os.linesep.join(d) @@ -401,7 +416,7 @@ class Client: pcrsel_len = max((i >> 3) + 1, 3) pcrsel = [0] * pcrsel_len pcrsel[i >> 3] = 1 << (i & 7) -pcrsel = ''.join(map(chr, pcrsel)) +pcrsel = ''.join(map(chr, pcrsel)).encode() fmt = '>HII IHB%us' % (pcrsel_len) cmd = struct.pack(fmt, @@ -430,6 +445,8 @@ class Client:
[PATCH AUTOSEL 5.7 008/388] iio: pressure: bmp280: Tolerate IRQ before registering
From: Andy Shevchenko
[ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ]
With DEBUG_SHIRQ enabled we have a kernel crash
[ 116.482696] BUG: kernel NULL pointer dereference, address:
...
[ 116.606571] Call Trace:
[ 116.609023]
[ 116.611047] complete+0x34/0x50
[ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280]
because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers
ought to be able to handle an interrupt happening before request_irq() returns.
Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC
interrupt")
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
drivers/iio/pressure/bmp280-core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/pressure/bmp280-core.c
b/drivers/iio/pressure/bmp280-core.c
index 29c209cc1108..2540e7c2358c 100644
--- a/drivers/iio/pressure/bmp280-core.c
+++ b/drivers/iio/pressure/bmp280-core.c
@@ -713,7 +713,7 @@ static int bmp180_measure(struct bmp280_data *data, u8
ctrl_meas)
unsigned int ctrl;
if (data->use_eoc)
- init_completion(>done);
+ reinit_completion(>done);
ret = regmap_write(data->regmap, BMP280_REG_CTRL_MEAS, ctrl_meas);
if (ret)
@@ -969,6 +969,9 @@ static int bmp085_fetch_eoc_irq(struct device *dev,
"trying to enforce it\n");
irq_trig = IRQF_TRIGGER_RISING;
}
+
+ init_completion(>done);
+
ret = devm_request_threaded_irq(dev,
irq,
bmp085_eoc_irq,
--
2.25.1
[PATCH AUTOSEL 5.7 003/388] clk: sunxi: Fix incorrect usage of round_down()
From: Rikard Falkeborn
[ Upstream commit ee25d9742dabed3fd18158b518f846abeb70f319 ]
round_down() can only round to powers of 2. If round_down() is asked
to round to something that is not a power of 2, incorrect results are
produced. The incorrect results can be both too large and too small.
Instead, use rounddown() which can round to any number.
Fixes: 6a721db180a2 ("clk: sunxi: Add A31 clocks support")
Signed-off-by: Rikard Falkeborn
Signed-off-by: Maxime Ripard
Signed-off-by: Sasha Levin
---
drivers/clk/sunxi/clk-sunxi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 27201fd26e44..e1aa1fbac48a 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -90,7 +90,7 @@ static void sun6i_a31_get_pll1_factors(struct factors_request
*req)
* Round down the frequency to the closest multiple of either
* 6 or 16
*/
- u32 round_freq_6 = round_down(freq_mhz, 6);
+ u32 round_freq_6 = rounddown(freq_mhz, 6);
u32 round_freq_16 = round_down(freq_mhz, 16);
if (round_freq_6 > round_freq_16)
--
2.25.1
[PATCH AUTOSEL 5.7 019/388] arm64: dts: renesas: Fix IOMMU device node names
From: Yoshihiro Shimoda
[ Upstream commit cf8ae446bbcbf5c48214eb7ddaa6ac6e12f4633d ]
Fix IOMMU device node names as "iommu@".
Fixes: 8f507babc617 ("arm64: dts: renesas: r8a774a1: Add IPMMU device nodes")
Fixes: 63093a8e58be ("arm64: dts: renesas: r8a774b1: Add IPMMU device nodes")
Fixes: 6c7e02178e8f ("arm64: dts: renesas: r8a774c0: Add IPMMU device nodes")
Fixes: 3b7e7848f0e8 ("arm64: dts: renesas: r8a7795: Add IPMMU device nodes")
Fixes: e4b9a493df45 ("arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes")
Fixes: 389baa409617 ("arm64: dts: renesas: r8a7796: Add IPMMU device nodes")
Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU devices
nodes")
Fixes: ce3b52a1595b ("arm64: dts: renesas: r8a77970: Add IPMMU device nodes")
Fixes: a3901e7398e1 ("arm64: dts: renesas: r8a77995: Add IPMMU device nodes")
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Niklas Söderlund
Link:
https://lore.kernel.org/r/1587461775-13369-1-git-send-email-yoshihiro.shimoda...@renesas.com
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 18 ++--
arch/arm64/boot/dts/renesas/r8a774b1.dtsi | 18 ++--
arch/arm64/boot/dts/renesas/r8a774c0.dtsi | 18 ++--
arch/arm64/boot/dts/renesas/r8a77950.dtsi | 14 +-
arch/arm64/boot/dts/renesas/r8a77951.dtsi | 34 +++
arch/arm64/boot/dts/renesas/r8a77960.dtsi | 22 +++
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 20 ++---
arch/arm64/boot/dts/renesas/r8a77970.dtsi | 10 +++
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 16 +--
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 20 ++---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 ++---
11 files changed, 105 insertions(+), 105 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 79023433a740..a603d947970e 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -1000,7 +1000,7 @@ dmac2: dma-controller@e731 {
<_ds1 30>, <_ds1 31>;
};
- ipmmu_ds0: mmu@e674 {
+ ipmmu_ds0: iommu@e674 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe674 0 0x1000>;
renesas,ipmmu-main = <_mm 0>;
@@ -1008,7 +1008,7 @@ ipmmu_ds0: mmu@e674 {
#iommu-cells = <1>;
};
- ipmmu_ds1: mmu@e774 {
+ ipmmu_ds1: iommu@e774 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe774 0 0x1000>;
renesas,ipmmu-main = <_mm 1>;
@@ -1016,7 +1016,7 @@ ipmmu_ds1: mmu@e774 {
#iommu-cells = <1>;
};
- ipmmu_hc: mmu@e657 {
+ ipmmu_hc: iommu@e657 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe657 0 0x1000>;
renesas,ipmmu-main = <_mm 2>;
@@ -1024,7 +1024,7 @@ ipmmu_hc: mmu@e657 {
#iommu-cells = <1>;
};
- ipmmu_mm: mmu@e67b {
+ ipmmu_mm: iommu@e67b {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xe67b 0 0x1000>;
interrupts = ,
@@ -1033,7 +1033,7 @@ ipmmu_mm: mmu@e67b {
#iommu-cells = <1>;
};
- ipmmu_mp: mmu@ec67 {
+ ipmmu_mp: iommu@ec67 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xec67 0 0x1000>;
renesas,ipmmu-main = <_mm 4>;
@@ -1041,7 +1041,7 @@ ipmmu_mp: mmu@ec67 {
#iommu-cells = <1>;
};
- ipmmu_pv0: mmu@fd80 {
+ ipmmu_pv0: iommu@fd80 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfd80 0 0x1000>;
renesas,ipmmu-main = <_mm 5>;
@@ -1049,7 +1049,7 @@ ipmmu_pv0: mmu@fd80 {
#iommu-cells = <1>;
};
- ipmmu_pv1: mmu@fd95 {
+ ipmmu_pv1: iommu@fd95 {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfd95 0 0x1000>;
renesas,ipmmu-main = <_mm 6>;
@@ -1057,7 +1057,7 @@ ipmmu_pv1: mmu@fd95 {
#iommu-cells = <1>;
};
- ipmmu_vc0: mmu@fe6b {
+ ipmmu_vc0: iommu@fe6b {
compatible = "renesas,ipmmu-r8a774a1";
reg = <0 0xfe6b 0 0x1000>;
renesas,ipmmu-main =
[PATCH AUTOSEL 5.7 017/388] ARM: integrator: Add some Kconfig selections
From: Linus Walleij [ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ] The CMA and DMA_CMA Kconfig options need to be selected by the Integrator in order to produce boot console on some Integrator systems. The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be selected in order to boot the system from an external MMC card when using MMCI/PL181 from the device tree probe path. Select these things directly from the Kconfig so we are sure to be able to bring the systems up with console from any device tree. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin --- arch/arm/mach-integrator/Kconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig index 982eabc36163..2406cab73835 100644 --- a/arch/arm/mach-integrator/Kconfig +++ b/arch/arm/mach-integrator/Kconfig @@ -4,6 +4,8 @@ menuconfig ARCH_INTEGRATOR depends on ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V6 select ARM_AMBA select COMMON_CLK_VERSATILE + select CMA + select DMA_CMA select HAVE_TCM select ICST select MFD_SYSCON @@ -35,14 +37,13 @@ config INTEGRATOR_IMPD1 select ARM_VIC select GPIO_PL061 select GPIOLIB + select REGULATOR + select REGULATOR_FIXED_VOLTAGE help The IM-PD1 is an add-on logic module for the Integrator which allows ARM(R) Ltd PrimeCells to be developed and evaluated. The IM-PD1 can be found on the Integrator/PP2 platform. - To compile this driver as a module, choose M here: the - module will be called impd1. - config INTEGRATOR_CM7TDMI bool "Integrator/CM7TDMI core module" depends on ARCH_INTEGRATOR_AP -- 2.25.1
[PATCH AUTOSEL 5.7 025/388] ALSA: hda/realtek - Introduce polarity for micmute LED GPIO
From: Kai-Heng Feng
[ Upstream commit dbd13179780555ecd3c992dea1222ca31920e892 ]
Currently mute LED and micmute LED share the same GPIO polarity.
So split the polarity for mute and micmute, in case they have different
polarities.
Signed-off-by: Kai-Heng Feng
Link:
https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.f...@canonical.com
Signed-off-by: Takashi Iwai
Signed-off-by: Sasha Levin
---
sound/pci/hda/patch_realtek.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 2c4575909441..e057ecb5a904 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -81,6 +81,7 @@ struct alc_spec {
/* mute LED for HP laptops, see alc269_fixup_mic_mute_hook() */
int mute_led_polarity;
+ int micmute_led_polarity;
hda_nid_t mute_led_nid;
hda_nid_t cap_mute_led_nid;
@@ -4080,11 +4081,9 @@ static void alc269_fixup_hp_mute_led_mic3(struct
hda_codec *codec,
/* update LED status via GPIO */
static void alc_update_gpio_led(struct hda_codec *codec, unsigned int mask,
- bool enabled)
+ int polarity, bool enabled)
{
- struct alc_spec *spec = codec->spec;
-
- if (spec->mute_led_polarity)
+ if (polarity)
enabled = !enabled;
alc_update_gpio_data(codec, mask, !enabled); /* muted -> LED on */
}
@@ -4095,7 +4094,8 @@ static void alc_fixup_gpio_mute_hook(void *private_data,
int enabled)
struct hda_codec *codec = private_data;
struct alc_spec *spec = codec->spec;
- alc_update_gpio_led(codec, spec->gpio_mute_led_mask, enabled);
+ alc_update_gpio_led(codec, spec->gpio_mute_led_mask,
+ spec->mute_led_polarity, enabled);
}
/* turn on/off mic-mute LED via GPIO per capture hook */
@@ -4104,6 +4104,7 @@ static void alc_gpio_micmute_update(struct hda_codec
*codec)
struct alc_spec *spec = codec->spec;
alc_update_gpio_led(codec, spec->gpio_mic_led_mask,
+ spec->micmute_led_polarity,
spec->gen.micmute_led.led_value);
}
@@ -5808,7 +5809,8 @@ static void alc280_hp_gpio4_automute_hook(struct
hda_codec *codec,
snd_hda_gen_hp_automute(codec, jack);
/* mute_led_polarity is set to 0, so we pass inverted value here */
- alc_update_gpio_led(codec, 0x10, !spec->gen.hp_jack_present);
+ alc_update_gpio_led(codec, 0x10, spec->mute_led_polarity,
+ !spec->gen.hp_jack_present);
}
/* Manage GPIOs for HP EliteBook Folio 9480m.
--
2.25.1
[PATCH AUTOSEL 5.7 024/388] arm64: dts: meson: fixup SCP sram nodes
From: Neil Armstrong
[ Upstream commit 9ecded10b4b6af238da0c86197b0418912e7513e ]
The GX and AXG SCP sram nodes were using invalid compatible and
node names for the sram entries.
Fixup the sram entries node names, and use proper compatible for them.
It notably fixes:
sram@c800: 'scp-shmem@0', 'scp-shmem@200' do not match any of the regexes:
'^([a-z]*-)?sram(-section)?@[a-f0-9]+$', 'pinctrl-[0-9]+'
Signed-off-by: Neil Armstrong
Signed-off-by: Kevin Hilman
Link: https://lore.kernel.org/r/20200326165958.19274-3-narmstr...@baylibre.com
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 6 +++---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 10 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index aace3d32a3df..8e6281c685fa 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1735,18 +1735,18 @@ sd_emmc_c: mmc@7000 {
};
sram: sram@fffc {
- compatible = "amlogic,meson-axg-sram", "mmio-sram";
+ compatible = "mmio-sram";
reg = <0x0 0xfffc 0x0 0x2>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0xfffc 0x2>;
- cpu_scp_lpri: scp-shmem@13000 {
+ cpu_scp_lpri: scp-sram@13000 {
compatible = "amlogic,meson-axg-scp-shmem";
reg = <0x13000 0x400>;
};
- cpu_scp_hpri: scp-shmem@13400 {
+ cpu_scp_hpri: scp-sram@13400 {
compatible = "amlogic,meson-axg-scp-shmem";
reg = <0x13400 0x400>;
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 03f79fe045b7..e2bb68ec8502 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -398,20 +398,20 @@ gic: interrupt-controller@c4301000 {
};
sram: sram@c800 {
- compatible = "amlogic,meson-gx-sram",
"amlogic,meson-gxbb-sram", "mmio-sram";
+ compatible = "mmio-sram";
reg = <0x0 0xc800 0x0 0x14000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0xc800 0x14000>;
- cpu_scp_lpri: scp-shmem@0 {
- compatible = "amlogic,meson-gx-scp-shmem",
"amlogic,meson-gxbb-scp-shmem";
+ cpu_scp_lpri: scp-sram@0 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
reg = <0x13000 0x400>;
};
- cpu_scp_hpri: scp-shmem@200 {
- compatible = "amlogic,meson-gx-scp-shmem",
"amlogic,meson-gxbb-scp-shmem";
+ cpu_scp_hpri: scp-sram@200 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
reg = <0x13400 0x400>;
};
};
--
2.25.1
[PATCH AUTOSEL 5.7 023/388] scsi: qedi: Check for buffer overflow in qedi_set_path()
From: Dan Carpenter
[ Upstream commit 4a4c0cfb4be74e216dd4446b254594707455bfc6 ]
Smatch complains that the "path_data->handle" variable is user controlled.
It comes from iscsi_set_path() so that seems possible. It's harmless to
add a limit check.
The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is
always ISCSI_MAX_SESS_PER_HBA (4096) elements). The array is allocated in
the qedi_cm_alloc_mem() function.
Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda
Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver
framework.")
Acked-by: Manish Rangankar
Signed-off-by: Dan Carpenter
Signed-off-by: Martin K. Petersen
Signed-off-by: Sasha Levin
---
drivers/scsi/qedi/qedi_iscsi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index 1f4a5fb00a05..d2e5b485afeb 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1218,6 +1218,10 @@ static int qedi_set_path(struct Scsi_Host *shost, struct
iscsi_path *path_data)
}
iscsi_cid = (u32)path_data->handle;
+ if (iscsi_cid >= qedi->max_active_conns) {
+ ret = -EINVAL;
+ goto set_path_exit;
+ }
qedi_ep = qedi->ep_tbl[iscsi_cid];
QEDI_INFO(>dbg_ctx, QEDI_LOG_INFO,
"iscsi_cid=0x%x, qedi_ep=%p\n", iscsi_cid, qedi_ep);
--
2.25.1
[PATCH AUTOSEL 5.7 015/388] ARM: dts: renesas: Fix IOMMU device node names
From: Yoshihiro Shimoda
[ Upstream commit ae990a1de014396ffc8d0fcc31b6888c9b0ce59a ]
Fix IOMMU device node names as "iommu@".
Fixes: bbb44da0b595 ("ARM: dts: r8a7743: Add IPMMU DT nodes")
Fixes: 0dcba3de5835 ("ARM: dts: r8a7745: Add IPMMU DT nodes")
Fixes: 350ae49b97c4 ("ARM: dts: r8a7744: Add IPMMU DT nodes")
Fixes: 70496727c082 ("ARM: shmobile: r8a7790: Add IPMMU DT nodes")
Fixes: f1951852ed17 ("ARM: shmobile: r8a7791: Add IPMMU DT nodes")
Fixes: 098cb3a601e6 ("ARM: shmobile: r8a7793: Add IPMMU nodes")
Fixes: 1cb2794f6082 ("ARM: shmobile: r8a7794: Add IPMMU DT nodes")
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Niklas Söderlund
Link:
https://lore.kernel.org/r/1587461756-13317-1-git-send-email-yoshihiro.shimoda...@renesas.com
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/r8a7743.dtsi | 12 ++--
arch/arm/boot/dts/r8a7744.dtsi | 12 ++--
arch/arm/boot/dts/r8a7745.dtsi | 12 ++--
arch/arm/boot/dts/r8a7790.dtsi | 12 ++--
arch/arm/boot/dts/r8a7791.dtsi | 14 +++---
arch/arm/boot/dts/r8a7793.dtsi | 14 +++---
arch/arm/boot/dts/r8a7794.dtsi | 12 ++--
7 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index e8b340bb99bc..fff123753b85 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -338,7 +338,7 @@ thermal: thermal@e61f {
#thermal-sensor-cells = <0>;
};
- ipmmu_sy0: mmu@e628 {
+ ipmmu_sy0: iommu@e628 {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xe628 0 0x1000>;
@@ -348,7 +348,7 @@ ipmmu_sy0: mmu@e628 {
status = "disabled";
};
- ipmmu_sy1: mmu@e629 {
+ ipmmu_sy1: iommu@e629 {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xe629 0 0x1000>;
@@ -357,7 +357,7 @@ ipmmu_sy1: mmu@e629 {
status = "disabled";
};
- ipmmu_ds: mmu@e674 {
+ ipmmu_ds: iommu@e674 {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xe674 0 0x1000>;
@@ -367,7 +367,7 @@ ipmmu_ds: mmu@e674 {
status = "disabled";
};
- ipmmu_mp: mmu@ec68 {
+ ipmmu_mp: iommu@ec68 {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xec68 0 0x1000>;
@@ -376,7 +376,7 @@ ipmmu_mp: mmu@ec68 {
status = "disabled";
};
- ipmmu_mx: mmu@fe951000 {
+ ipmmu_mx: iommu@fe951000 {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xfe951000 0 0x1000>;
@@ -386,7 +386,7 @@ ipmmu_mx: mmu@fe951000 {
status = "disabled";
};
- ipmmu_gp: mmu@e62a {
+ ipmmu_gp: iommu@e62a {
compatible = "renesas,ipmmu-r8a7743",
"renesas,ipmmu-vmsa";
reg = <0 0xe62a 0 0x1000>;
diff --git a/arch/arm/boot/dts/r8a7744.dtsi b/arch/arm/boot/dts/r8a7744.dtsi
index def840b8b2d3..5050ac19041d 100644
--- a/arch/arm/boot/dts/r8a7744.dtsi
+++ b/arch/arm/boot/dts/r8a7744.dtsi
@@ -338,7 +338,7 @@ thermal: thermal@e61f {
#thermal-sensor-cells = <0>;
};
- ipmmu_sy0: mmu@e628 {
+ ipmmu_sy0: iommu@e628 {
compatible = "renesas,ipmmu-r8a7744",
"renesas,ipmmu-vmsa";
reg = <0 0xe628 0 0x1000>;
@@ -348,7 +348,7 @@ ipmmu_sy0: mmu@e628 {
status = "disabled";
};
- ipmmu_sy1: mmu@e629 {
+ ipmmu_sy1: iommu@e629 {
compatible = "renesas,ipmmu-r8a7744",
"renesas,ipmmu-vmsa";
reg = <0 0xe629 0 0x1000>;
@@ -357,7 +357,7 @@ ipmmu_sy1: mmu@e629 {
status = "disabled";
};
- ipmmu_ds: mmu@e674 {
+ ipmmu_ds: iommu@e674 {
compatible = "renesas,ipmmu-r8a7744",
"renesas,ipmmu-vmsa";
reg = <0 0xe674 0 0x1000>;
@@ -367,7 +367,7 @@
[PATCH AUTOSEL 5.7 026/388] ALSA: isa/wavefront: prevent out of bounds write in ioctl
From: Dan Carpenter [ Upstream commit 7f0d5053c5a9d23fe5c2d337495a9d79038d267b ] The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin --- sound/isa/wavefront/wavefront_synth.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/isa/wavefront/wavefront_synth.c b/sound/isa/wavefront/wavefront_synth.c index c5b1d5900eed..d6420d224d09 100644 --- a/sound/isa/wavefront/wavefront_synth.c +++ b/sound/isa/wavefront/wavefront_synth.c @@ -1171,7 +1171,10 @@ wavefront_send_alias (snd_wavefront_t *dev, wavefront_patch_info *header) "alias for %d\n", header->number, header->hdr.a.OriginalSample); - + + if (header->number >= WF_MAX_SAMPLE) + return -EINVAL; + munge_int32 (header->number, _hdr[0], 2); munge_int32 (header->hdr.a.OriginalSample, _hdr[2], 2); munge_int32 (*((unsigned int *)>hdr.a.sampleStartOffset), @@ -1202,6 +1205,9 @@ wavefront_send_multisample (snd_wavefront_t *dev, wavefront_patch_info *header) int num_samples; unsigned char *msample_hdr; + if (header->number >= WF_MAX_SAMPLE) + return -EINVAL; + msample_hdr = kmalloc(WF_MSAMPLE_BYTES, GFP_KERNEL); if (! msample_hdr) return -ENOMEM; -- 2.25.1
[PATCH AUTOSEL 5.7 027/388] PCI: Allow pci_resize_resource() for devices on root bus
From: Ard Biesheuvel
[ Upstream commit d09ddd8190fbdc07696bf34b548ae15aa1816714 ]
When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring
the bridge windows of parent bridges in line with the new BAR assignment.
This assumes the device whose BAR is being resized lives on a subordinate
bus, but this is not necessarily the case. A device may live on the root
bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev
pointer to pci_reassign_bridge_resources() will cause it to crash.
So let's make the call to pci_reassign_bridge_resources() conditional on
whether dev->bus->self is non-NULL in the first place.
Fixes: 8bb705e3e79d84e7 ("PCI: Add pci_resize_resource() for resizing BARs")
Link: https://lore.kernel.org/r/20200421162256.26887-1-a...@kernel.org
Signed-off-by: Ard Biesheuvel
Signed-off-by: Bjorn Helgaas
Reviewed-by: Christian König
Signed-off-by: Sasha Levin
---
drivers/pci/setup-res.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index d8ca40a97693..d21fa04fa44d 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -439,10 +439,11 @@ int pci_resize_resource(struct pci_dev *dev, int resno,
int size)
res->end = res->start + pci_rebar_size_to_bytes(size) - 1;
/* Check if the new config works by trying to assign everything. */
- ret = pci_reassign_bridge_resources(dev->bus->self, res->flags);
- if (ret)
- goto error_resize;
-
+ if (dev->bus->self) {
+ ret = pci_reassign_bridge_resources(dev->bus->self, res->flags);
+ if (ret)
+ goto error_resize;
+ }
return 0;
error_resize:
--
2.25.1
[PATCH AUTOSEL 5.7 032/388] powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT
From: Christophe Leroy
[ Upstream commit edbadaf0671072298e506074128b64e003c5812c ]
When CONFIG_KASAN is selected, the stack usage is increased.
In the same way as x86 and arm64 architectures, increase
THREAD_SHIFT when CONFIG_KASAN is selected.
Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
Reported-by:
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207129
Link:
https://lore.kernel.org/r/2c50f3b1c9bbaa4217c9a98f3044bd2a36c46a4f.1586361277.git.christophe.le...@c-s.fr
Signed-off-by: Sasha Levin
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b29d7cb38368..51a074c26793 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -773,6 +773,7 @@ config THREAD_SHIFT
range 13 15
default "15" if PPC_256K_PAGES
default "14" if PPC64
+ default "14" if KASAN
default "13"
help
Used to define the stack size. The default is almost always what you
--
2.25.1
[PATCH AUTOSEL 5.7 028/388] PCI: endpoint: functions/pci-epf-test: Fix DMA channel release
From: Kunihiko Hayashi
[ Upstream commit 0e86d981f9b7252e9716c5137cd8e4d9ad8ef32f ]
When unbinding pci_epf_test, pci_epf_test_clean_dma_chan() is called in
pci_epf_test_unbind() even though epf_test->dma_supported is false.
As a result, dma_release_channel() will trigger a NULL pointer
dereference because dma_chan is not set.
Avoid calling dma_release_channel() if epf_test->dma_supported
is false.
Link:
https://lore.kernel.org/r/1587540287-10458-1-git-send-email-hayashi.kunih...@socionext.com
Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to
transfer data")
Signed-off-by: Kunihiko Hayashi
[lorenzo.pieral...@arm.com: commit log]
Signed-off-by: Lorenzo Pieralisi
Acked-by: Kishon Vijay Abraham I
Signed-off-by: Sasha Levin
---
drivers/pci/endpoint/functions/pci-epf-test.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 60330f3e3751..c89a9561439f 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -187,6 +187,9 @@ static int pci_epf_test_init_dma_chan(struct pci_epf_test
*epf_test)
*/
static void pci_epf_test_clean_dma_chan(struct pci_epf_test *epf_test)
{
+ if (!epf_test->dma_supported)
+ return;
+
dma_release_channel(epf_test->dma_chan);
epf_test->dma_chan = NULL;
}
--
2.25.1
[PATCH AUTOSEL 5.7 036/388] f2fs: report delalloc reserve as non-free in statfs for project quota
From: Konstantin Khlebnikov
[ Upstream commit baaa7ebf25c78c5cb712fac16b7f549100beddd3 ]
This reserved space isn't committed yet but cannot be used for
allocations. For userspace it has no difference from used space.
See the same fix in ext4 commit f06925c73942 ("ext4: report delalloc
reserve as non-free in statfs for project quota").
Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project")
Signed-off-by: Konstantin Khlebnikov
Reviewed-by: Chao Yu
Signed-off-by: Jaegeuk Kim
Signed-off-by: Sasha Levin
---
fs/f2fs/super.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f2dfc21c6abb..c5e8cb31626f 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1292,7 +1292,8 @@ static int f2fs_statfs_project(struct super_block *sb,
limit >>= sb->s_blocksize_bits;
if (limit && buf->f_blocks > limit) {
- curblock = dquot->dq_dqb.dqb_curspace >> sb->s_blocksize_bits;
+ curblock = (dquot->dq_dqb.dqb_curspace +
+ dquot->dq_dqb.dqb_rsvspace) >> sb->s_blocksize_bits;
buf->f_blocks = limit;
buf->f_bfree = buf->f_bavail =
(buf->f_blocks > curblock) ?
--
2.25.1
[PATCH AUTOSEL 5.7 033/388] rtc: mc13xxx: fix a double-unlock issue
From: Qiushi Wu
[ Upstream commit 8816cd726a4fee197af2d851cbe25991ae19ea14 ]
In function mc13xxx_rtc_probe, the mc13xxx_unlock() is called
before rtc_register_device(). But in the error path of
rtc_register_device(), the mc13xxx_unlock() is called again,
which causes a double-unlock problem. Thus add a call of the
function “mc13xxx_lock” in an if branch for the completion
of the exception handling.
Fixes: e4ae7023e182a ("rtc: mc13xxx: set range")
Signed-off-by: Qiushi Wu
Link: https://lore.kernel.org/r/20200503182235.1652-1-wu000...@umn.edu
Signed-off-by: Alexandre Belloni
Signed-off-by: Sasha Levin
---
drivers/rtc/rtc-mc13xxx.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-mc13xxx.c b/drivers/rtc/rtc-mc13xxx.c
index afce2c0b4bd6..d6802e6191cb 100644
--- a/drivers/rtc/rtc-mc13xxx.c
+++ b/drivers/rtc/rtc-mc13xxx.c
@@ -308,8 +308,10 @@ static int __init mc13xxx_rtc_probe(struct platform_device
*pdev)
mc13xxx_unlock(mc13xxx);
ret = rtc_register_device(priv->rtc);
- if (ret)
+ if (ret) {
+ mc13xxx_lock(mc13xxx);
goto err_irq_request;
+ }
return 0;
--
2.25.1
[PATCH AUTOSEL 5.7 043/388] serial: 8250: Fix max baud limit in generic 8250 port
From: Serge Semin
[ Upstream commit 7b668c064ec33f3d687c3a413d05e355172e6c92 ]
Standard 8250 UART ports are designed in a way so they can communicate
with baud rates up to 1/16 of a reference frequency. It's expected from
most of the currently supported UART controllers. That's why the former
version of serial8250_get_baud_rate() method called uart_get_baud_rate()
with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX)
and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like
it was suggested in commit ("serial: 8250_mtk: support big baud rate."),
caused acceptance of bauds, which was higher than the normal UART
controllers actually supported. As a result if some user-space program
requested to set a baud greater than (uartclk / 16) it would have been
permitted without truncation, but then serial8250_get_divisor(baud)
(which calls uart_get_divisor() to get the reference clock divisor) would
have returned a zero divisor. Setting zero divisor will cause an
unpredictable effect varying from chip to chip. In case of DW APB UART the
communications just stop.
Lets fix this problem by getting back the limitation of (uartclk +
tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek
8250 UART ports driver developer shouldn't have touched it in the first
place notably seeing he already provided a custom version of set_termios()
callback in that glue-driver which took into account the extended baud
rate values and accordingly updated the standard and vendor-specific
divisor latch registers anyway.
Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.")
Signed-off-by: Serge Semin
Cc: Alexey Malahov
Cc: Thomas Bogendoerfer
Cc: Paul Burton
Cc: Ralf Baechle
Cc: Arnd Bergmann
Cc: Long Cheng
Cc: Andy Shevchenko
Cc: Maxime Ripard
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Russell King
Cc: linux-m...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Link:
https://lore.kernel.org/r/20200506233136.11842-2-sergey.se...@baikalelectronics.ru
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/tty/serial/8250/8250_port.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_port.c
b/drivers/tty/serial/8250/8250_port.c
index f77bf820b7a3..4d83c85a7389 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2615,6 +2615,8 @@ static unsigned int serial8250_get_baud_rate(struct
uart_port *port,
struct ktermios *termios,
struct ktermios *old)
{
+ unsigned int tolerance = port->uartclk / 100;
+
/*
* Ask the core to calculate the divisor for us.
* Allow 1% tolerance at the upper limit so uart clks marginally
@@ -2623,7 +2625,7 @@ static unsigned int serial8250_get_baud_rate(struct
uart_port *port,
*/
return uart_get_baud_rate(port, termios, old,
port->uartclk / 16 / UART_DIV_MAX,
- port->uartclk);
+ (port->uartclk + tolerance) / 16);
}
void
--
2.25.1
[PATCH AUTOSEL 5.7 034/388] iio: bmp280: fix compensation of humidity
From: Andreas Klinger [ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ] Limit the output of humidity compensation to the range between 0 and 100 percent. Depending on the calibration parameters of the individual sensor it happens, that a humidity above 100 percent or below 0 percent is calculated, which don't make sense in terms of relative humidity. Add a clamp to the compensation formula as described in the datasheet of the sensor in chapter 4.2.3. Although this clamp is documented, it was never in the driver of the kernel. It depends on the circumstances (calibration parameters, temperature, humidity) if one can see a value above 100 percent without the clamp. The writer of this patch was working with this type of sensor without noting this error. So it seems to be a rare event when this bug occures. Signed-off-by: Andreas Klinger Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin --- drivers/iio/pressure/bmp280-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/pressure/bmp280-core.c b/drivers/iio/pressure/bmp280-core.c index 2540e7c2358c..973264a088f9 100644 --- a/drivers/iio/pressure/bmp280-core.c +++ b/drivers/iio/pressure/bmp280-core.c @@ -271,6 +271,8 @@ static u32 bmp280_compensate_humidity(struct bmp280_data *data, + (s32)2097152) * calib->H2 + 8192) >> 14); var -= var >> 15) * (var >> 15)) >> 7) * (s32)calib->H1) >> 4; + var = clamp_val(var, 0, 419430400); + return var >> 12; }; -- 2.25.1
[PATCH AUTOSEL 5.7 046/388] misc: fastrpc: fix potential fastrpc_invoke_ctx leak
From: Srinivas Kandagatla
[ Upstream commit 74003385cf716f1b88cc7753ca282f5493f204a2 ]
fastrpc_invoke_ctx can have refcount of 2 in error path where
rpmsg_send() fails to send invoke message. decrement the refcount
properly in the error path to fix this leak.
This also fixes below static checker warning:
drivers/misc/fastrpc.c:990 fastrpc_internal_invoke()
warn: 'ctx->refcount.refcount.ref.counter' not decremented on lines: 990.
Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context")
Reported-by: Dan Carpenter
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Bjorn Andersson
Link:
https://lore.kernel.org/r/20200512110930.2550-1-srinivas.kandaga...@linaro.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/misc/fastrpc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 9065d3e71ff7..7939c55daceb 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -904,6 +904,7 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx
*sctx,
struct fastrpc_channel_ctx *cctx;
struct fastrpc_user *fl = ctx->fl;
struct fastrpc_msg *msg = >msg;
+ int ret;
cctx = fl->cctx;
msg->pid = fl->tgid;
@@ -919,7 +920,13 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx
*sctx,
msg->size = roundup(ctx->msg_sz, PAGE_SIZE);
fastrpc_context_get(ctx);
- return rpmsg_send(cctx->rpdev->ept, (void *)msg, sizeof(*msg));
+ ret = rpmsg_send(cctx->rpdev->ept, (void *)msg, sizeof(*msg));
+
+ if (ret)
+ fastrpc_context_put(ctx);
+
+ return ret;
+
}
static int fastrpc_internal_invoke(struct fastrpc_user *fl, u32 kernel,
--
2.25.1
[PATCH AUTOSEL 5.7 044/388] nvmem: ensure sysfs writes handle write-protect pin
From: Michael Auchter
[ Upstream commit b96fc5416b099a0c2509ca07a80b140d34db2b9b ]
Commit 2a127da461a9 ("nvmem: add support for the write-protect pin")
added support for handling write-protect pins to the nvmem core, and
Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support")
retrofitted the at24 driver to use this support.
These changes broke write() on the nvmem sysfs attribute for eeproms
which utilize a write-protect pin, as the write callback invokes the
nvmem device's reg_write callback directly which no longer handles
changing the state of the write-protect pin.
Change the read and write callbacks for the sysfs attribute to invoke
nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than
calling reg_read/reg_write directly.
Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin")
Signed-off-by: Michael Auchter
Signed-off-by: Srinivas Kandagatla
Link:
https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandaga...@linaro.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/nvmem/core.c | 52 ++--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 05c6ae4b0b97..a8300202a7fb 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -66,6 +66,30 @@ static LIST_HEAD(nvmem_lookup_list);
static BLOCKING_NOTIFIER_HEAD(nvmem_notifier);
+static int nvmem_reg_read(struct nvmem_device *nvmem, unsigned int offset,
+ void *val, size_t bytes)
+{
+ if (nvmem->reg_read)
+ return nvmem->reg_read(nvmem->priv, offset, val, bytes);
+
+ return -EINVAL;
+}
+
+static int nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
+ void *val, size_t bytes)
+{
+ int ret;
+
+ if (nvmem->reg_write) {
+ gpiod_set_value_cansleep(nvmem->wp_gpio, 0);
+ ret = nvmem->reg_write(nvmem->priv, offset, val, bytes);
+ gpiod_set_value_cansleep(nvmem->wp_gpio, 1);
+ return ret;
+ }
+
+ return -EINVAL;
+}
+
#ifdef CONFIG_NVMEM_SYSFS
static const char * const nvmem_type_str[] = {
[NVMEM_TYPE_UNKNOWN] = "Unknown",
@@ -122,7 +146,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
struct kobject *kobj,
if (!nvmem->reg_read)
return -EPERM;
- rc = nvmem->reg_read(nvmem->priv, pos, buf, count);
+ rc = nvmem_reg_read(nvmem, pos, buf, count);
if (rc)
return rc;
@@ -159,7 +183,7 @@ static ssize_t bin_attr_nvmem_write(struct file *filp,
struct kobject *kobj,
if (!nvmem->reg_write)
return -EPERM;
- rc = nvmem->reg_write(nvmem->priv, pos, buf, count);
+ rc = nvmem_reg_write(nvmem, pos, buf, count);
if (rc)
return rc;
@@ -311,30 +335,6 @@ static void nvmem_sysfs_remove_compat(struct nvmem_device
*nvmem,
#endif /* CONFIG_NVMEM_SYSFS */
-static int nvmem_reg_read(struct nvmem_device *nvmem, unsigned int offset,
- void *val, size_t bytes)
-{
- if (nvmem->reg_read)
- return nvmem->reg_read(nvmem->priv, offset, val, bytes);
-
- return -EINVAL;
-}
-
-static int nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
- void *val, size_t bytes)
-{
- int ret;
-
- if (nvmem->reg_write) {
- gpiod_set_value_cansleep(nvmem->wp_gpio, 0);
- ret = nvmem->reg_write(nvmem->priv, offset, val, bytes);
- gpiod_set_value_cansleep(nvmem->wp_gpio, 1);
- return ret;
- }
-
- return -EINVAL;
-}
-
static void nvmem_release(struct device *dev)
{
struct nvmem_device *nvmem = to_nvmem_device(dev);
--
2.25.1
[PATCH AUTOSEL 5.7 040/388] staging: wfx: fix output of rx_stats on big endian hosts
From: Jérôme Pouiller
[ Upstream commit a823d6ecd4904e1a6ffb12964de88fb0bb4802f6 ]
The struct hif_rx_stats contains only little endian values. Thus, it is
necessary to fix byte ordering before to use them.
Signed-off-by: Jérôme Pouiller
Link:
https://lore.kernel.org/r/20200512150414.267198-6-jerome.pouil...@silabs.com
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/staging/wfx/debug.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wfx/debug.c b/drivers/staging/wfx/debug.c
index 1164aba118a1..a73b5bbb578e 100644
--- a/drivers/staging/wfx/debug.c
+++ b/drivers/staging/wfx/debug.c
@@ -142,7 +142,7 @@ static int wfx_rx_stats_show(struct seq_file *seq, void *v)
mutex_lock(>rx_stats_lock);
seq_printf(seq, "Timestamp: %dus\n", st->date);
seq_printf(seq, "Low power clock: frequency %uHz, external %s\n",
- st->pwr_clk_freq,
+ le32_to_cpu(st->pwr_clk_freq),
st->is_ext_pwr_clk ? "yes" : "no");
seq_printf(seq,
"Num. of frames: %d, PER (x10e4): %d, Throughput:
%dKbps/s\n",
@@ -152,9 +152,12 @@ static int wfx_rx_stats_show(struct seq_file *seq, void *v)
for (i = 0; i < ARRAY_SIZE(channel_names); i++) {
if (channel_names[i])
seq_printf(seq, "%5s %8d %8d %8d %8d %8d\n",
- channel_names[i], st->nb_rx_by_rate[i],
- st->per[i], st->rssi[i] / 100,
- st->snr[i] / 100, st->cfo[i]);
+ channel_names[i],
+ le32_to_cpu(st->nb_rx_by_rate[i]),
+ le16_to_cpu(st->per[i]),
+ (s16)le16_to_cpu(st->rssi[i]) / 100,
+ (s16)le16_to_cpu(st->snr[i]) / 100,
+ (s16)le16_to_cpu(st->cfo[i]));
}
mutex_unlock(>rx_stats_lock);
--
2.25.1
[PATCH AUTOSEL 5.7 045/388] misc: fastrpc: Fix an incomplete memory release in fastrpc_rpmsg_probe()
From: Srinivas Kandagatla
[ Upstream commit 0978de9fc7335c73934ab8fac189fb4cb3f23191 ]
fastrpc_channel_ctx is not freed if misc_register() fails, this would
lead to a memory leak. Fix this leak by adding kfree in misc_register()
error path.
Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context")
Signed-off-by: Srinivas Kandagatla
Reviewed-by: Bjorn Andersson
Link:
https://lore.kernel.org/r/20200511162722.2552-1-srinivas.kandaga...@linaro.org
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
---
drivers/misc/fastrpc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index e3e085e33d46..9065d3e71ff7 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -1613,8 +1613,10 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device
*rpdev)
domains[domain_id]);
data->miscdev.fops = _fops;
err = misc_register(>miscdev);
- if (err)
+ if (err) {
+ kfree(data);
return err;
+ }
kref_init(>refcount);
--
2.25.1
[PATCH AUTOSEL 5.7 048/388] arm64: dts: armada-3720-turris-mox: forbid SDR104 on SDIO for FCC purposes
From: Marek Behún
[ Upstream commit 7a2c36b039d2343cc29fec6102da839477b8dc60 ]
Use sdhci-caps-mask to forbid SDR104 mode on the SDIO capable SDHCI
controller. Without this the device cannot pass electromagnetic
interference certifications.
Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Marek Behún
Cc: Gregory CLEMENT
Signed-off-by: Gregory CLEMENT
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
index bb42d1e6a4e9..47fee66c70cb 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -179,6 +179,8 @@ {
marvell,pad-type = "sd";
vqmmc-supply = <_reg>;
mmc-pwrseq = <_pwrseq>;
+ /* forbid SDR104 for FCC purposes */
+ sdhci-caps-mask = <0x2 0x0>;
status = "okay";
};
--
2.25.1
[PATCH AUTOSEL 5.7 038/388] remoteproc: qcom_q6v5_mss: map/unmap mpss segments before/after use
From: Sibi Sankar
[ Upstream commit be050a3429f46ecf13eb2b80f299479f8bb823fb ]
The application processor accessing the mpss region when the Q6 modem is
running will lead to an XPU violation. Fix this by un-mapping the mpss
segments post copy during mpss authentication and coredumps.
Tested-by: Evan Green
Signed-off-by: Sibi Sankar
Link: https://lore.kernel.org/r/20200415071619.6052-1-si...@codeaurora.org
Signed-off-by: Bjorn Andersson
Signed-off-by: Sasha Levin
---
drivers/remoteproc/qcom_q6v5_mss.c | 31 +++---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 5475d4f808a8..22416e86a174 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1156,7 +1156,13 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
goto release_firmware;
}
- ptr = qproc->mpss_region + offset;
+ ptr = ioremap_wc(qproc->mpss_phys + offset, phdr->p_memsz);
+ if (!ptr) {
+ dev_err(qproc->dev,
+ "unable to map memory region: %pa+%zx-%x\n",
+ >mpss_phys, offset, phdr->p_memsz);
+ goto release_firmware;
+ }
if (phdr->p_filesz && phdr->p_offset < fw->size) {
/* Firmware is large enough to be non-split */
@@ -1165,6 +1171,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
"failed to load segment %d from
truncated file %s\n",
i, fw_name);
ret = -EINVAL;
+ iounmap(ptr);
goto release_firmware;
}
@@ -1175,6 +1182,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
ret = request_firmware(_fw, fw_name, qproc->dev);
if (ret) {
dev_err(qproc->dev, "failed to load %s\n",
fw_name);
+ iounmap(ptr);
goto release_firmware;
}
@@ -1187,6 +1195,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
memset(ptr + phdr->p_filesz, 0,
phdr->p_memsz - phdr->p_filesz);
}
+ iounmap(ptr);
size += phdr->p_memsz;
code_length = readl(qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
@@ -1236,7 +1245,8 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
int ret = 0;
struct q6v5 *qproc = rproc->priv;
unsigned long mask = BIT((unsigned long)segment->priv);
- void *ptr = rproc_da_to_va(rproc, segment->da, segment->size);
+ int offset = segment->da - qproc->mpss_reloc;
+ void *ptr = NULL;
/* Unlock mba before copying segments */
if (!qproc->dump_mba_loaded) {
@@ -1250,10 +1260,15 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
}
}
- if (!ptr || ret)
- memset(dest, 0xff, segment->size);
- else
+ if (!ret)
+ ptr = ioremap_wc(qproc->mpss_phys + offset, segment->size);
+
+ if (ptr) {
memcpy(dest, ptr, segment->size);
+ iounmap(ptr);
+ } else {
+ memset(dest, 0xff, segment->size);
+ }
qproc->dump_segment_mask |= mask;
@@ -1595,12 +1610,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
qproc->mpss_phys = qproc->mpss_reloc = r.start;
qproc->mpss_size = resource_size();
- qproc->mpss_region = devm_ioremap_wc(qproc->dev, qproc->mpss_phys,
qproc->mpss_size);
- if (!qproc->mpss_region) {
- dev_err(qproc->dev, "unable to map memory region: %pa+%zx\n",
- , qproc->mpss_size);
- return -EBUSY;
- }
return 0;
}
--
2.25.1
[PATCH AUTOSEL 5.7 050/388] arm64: dts: juno: Fix GIC child nodes
From: Andre Przywara
[ Upstream commit a78aee9e434932a500db36cc6d88daeff3745e9f ]
The GIC DT nodes for the Juno boards were not fully compliant with
the DT binding, which has certain expectations about child nodes and
their size and address cells values.
Use smaller #address-cells and #size-cells values, as the binding
requests, and adjust the reg properties accordingly.
This requires adjusting the interrupt nexus nodes as well, as one
field of the interrupt-map property depends on the GIC's address-size.
Link: https://lore.kernel.org/r/20200513103016.130417-10-andre.przyw...@arm.com
Signed-off-by: Andre Przywara
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 50 +-
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi
b/arch/arm64/boot/dts/arm/juno-base.dtsi
index f5889281545f..59b6ac0b828a 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -74,35 +74,35 @@ gic: interrupt-controller@2c01 {
<0x0 0x2c02f000 0 0x2000>,
<0x0 0x2c04f000 0 0x2000>,
<0x0 0x2c06f000 0 0x2000>;
- #address-cells = <2>;
+ #address-cells = <1>;
#interrupt-cells = <3>;
- #size-cells = <2>;
+ #size-cells = <1>;
interrupt-controller;
interrupts = ;
- ranges = <0 0 0 0x2c1c 0 0x4>;
+ ranges = <0 0 0x2c1c 0x4>;
v2m_0: v2m@0 {
compatible = "arm,gic-v2m-frame";
msi-controller;
- reg = <0 0 0 0x1>;
+ reg = <0 0x1>;
};
v2m@1 {
compatible = "arm,gic-v2m-frame";
msi-controller;
- reg = <0 0x1 0 0x1>;
+ reg = <0x1 0x1>;
};
v2m@2 {
compatible = "arm,gic-v2m-frame";
msi-controller;
- reg = <0 0x2 0 0x1>;
+ reg = <0x2 0x1>;
};
v2m@3 {
compatible = "arm,gic-v2m-frame";
msi-controller;
- reg = <0 0x3 0 0x1>;
+ reg = <0x3 0x1>;
};
};
@@ -546,10 +546,10 @@ pcie_ctlr: pcie@4000 {
<0x4200 0x40 0x 0x40 0x 0x1
0x>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 0 0 GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 0 0 GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 0 0 GIC_SPI 138
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 0 0 GIC_SPI 139
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 0 GIC_SPI 136
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 0 GIC_SPI 137
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 0 GIC_SPI 138
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 0 GIC_SPI 139
IRQ_TYPE_LEVEL_HIGH>;
msi-parent = <_0>;
status = "disabled";
iommu-map-mask = <0x0>; /* RC has no means to output PCI RID */
@@ -813,19 +813,19 @@ bus@800 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 15>;
- interrupt-map = <0 0 0 0 0 GIC_SPI 68
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 1 0 0 GIC_SPI 69
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 2 0 0 GIC_SPI 70
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 3 0 0 GIC_SPI 160
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 4 0 0 GIC_SPI 161
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 5 0 0 GIC_SPI 162
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 6 0 0 GIC_SPI 163
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 7 0 0 GIC_SPI 164
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 8 0 0 GIC_SPI 165
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 9 0 0 GIC_SPI 166
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 10 0 0 GIC_SPI 167
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 11 0 0 GIC_SPI 168
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 12 0 0 GIC_SPI 169
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 0 GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 1 0 GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 2 0 GIC_SPI 70
[PATCH AUTOSEL 5.7 054/388] clk: renesas: cpg-mssr: Fix STBCR suspend/resume handling
From: Geert Uytterhoeven
[ Upstream commit ace342097768e35fd41934285604fa97da1e235a ]
On SoCs with Standby Control Registers (STBCRs) instead of Module Stop
Control Registers (MSTPCRs), the suspend handler saves the wrong
registers, and the resume handler prints the wrong register in an error
message.
Fortunately this cannot happen yet, as the suspend/resume code is used
on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not
use PSCI. Still, it is better to fix this, to avoid this becoming a
problem in the future.
Distinguish between STBCRs and MSTPCRs where needed. Replace the
useless printing of the virtual register address in the resume error
message by printing the register index.
Fixes: fde35c9c7db5732c ("clk: renesas: cpg-mssr: Add R7S9210 support")
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20200507074713.30113-1-geert+rene...@glider.be
Signed-off-by: Sasha Levin
---
drivers/clk/renesas/renesas-cpg-mssr.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c
b/drivers/clk/renesas/renesas-cpg-mssr.c
index a2663fbbd7a5..d6a53c99b114 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -812,7 +812,8 @@ static int cpg_mssr_suspend_noirq(struct device *dev)
/* Save module registers with bits under our control */
for (reg = 0; reg < ARRAY_SIZE(priv->smstpcr_saved); reg++) {
if (priv->smstpcr_saved[reg].mask)
- priv->smstpcr_saved[reg].val =
+ priv->smstpcr_saved[reg].val = priv->stbyctrl ?
+ readb(priv->base + STBCR(reg)) :
readl(priv->base + SMSTPCR(reg));
}
@@ -872,8 +873,9 @@ static int cpg_mssr_resume_noirq(struct device *dev)
}
if (!i)
- dev_warn(dev, "Failed to enable SMSTP %p[0x%x]\n",
-priv->base + SMSTPCR(reg), oldval & mask);
+ dev_warn(dev, "Failed to enable %s%u[0x%x]\n",
+priv->stbyctrl ? "STB" : "SMSTP", reg,
+oldval & mask);
}
return 0;
--
2.25.1
[PATCH AUTOSEL 5.7 056/388] arm64: dts: fvp: Fix GIC child nodes
From: Andre Przywara
[ Upstream commit 78631aecc52c4b2adcf611769df2ff9c67ac16d0 ]
The GIC DT nodes for the fastmodels were not fully compliant with the
DT binding, which has certain expectations about child nodes and their
size and address cells values.
Use smaller #address-cells and #size-cells values, as the binding
requests, and adjust the reg properties accordingly.
This requires adjusting the interrupt nexus nodes as well, as one
field of the interrupt-map property depends on the GIC's address-size.
Since the .dts files share interrupt nexus nodes across different
interrupt controllers (GICv2 vs. GICv3), we need to use the only
commonly allowed #address-size value of <1> for both.
Link: https://lore.kernel.org/r/20200513103016.130417-11-andre.przyw...@arm.com
Signed-off-by: Andre Przywara
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
---
.../boot/dts/arm/foundation-v8-gicv2.dtsi | 2 +-
.../boot/dts/arm/foundation-v8-gicv3.dtsi | 8 +-
arch/arm64/boot/dts/arm/foundation-v8.dtsi| 86 +--
3 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
b/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
index 15fe81738e94..dfb23dfc0b0f 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
+++ b/arch/arm64/boot/dts/arm/foundation-v8-gicv2.dtsi
@@ -8,7 +8,7 @@ / {
gic: interrupt-controller@2c001000 {
compatible = "arm,cortex-a15-gic", "arm,cortex-a9-gic";
#interrupt-cells = <3>;
- #address-cells = <2>;
+ #address-cells = <1>;
interrupt-controller;
reg = <0x0 0x2c001000 0 0x1000>,
<0x0 0x2c002000 0 0x2000>,
diff --git a/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dtsi
b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dtsi
index f2c75c756039..906f51935b36 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dtsi
+++ b/arch/arm64/boot/dts/arm/foundation-v8-gicv3.dtsi
@@ -8,9 +8,9 @@ / {
gic: interrupt-controller@2f00 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
- #address-cells = <2>;
- #size-cells = <2>;
- ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x2f00 0x10>;
interrupt-controller;
reg = <0x0 0x2f00 0x0 0x1>,
<0x0 0x2f10 0x0 0x20>,
@@ -22,7 +22,7 @@ gic: interrupt-controller@2f00 {
its: its@2f02 {
compatible = "arm,gic-v3-its";
msi-controller;
- reg = <0x0 0x2f02 0x0 0x2>;
+ reg = <0x2 0x2>;
};
};
};
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
index 12f039fa3dad..60ec37d6c9d3 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
@@ -107,49 +107,49 @@ bus@800 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
- interrupt-map = <0 0 0 0 0 GIC_SPI 0
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 1 0 0 GIC_SPI 1
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 2 0 0 GIC_SPI 2
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 3 0 0 GIC_SPI 3
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 4 0 0 GIC_SPI 4
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 5 0 0 GIC_SPI 5
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 6 0 0 GIC_SPI 6
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 7 0 0 GIC_SPI 7
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 8 0 0 GIC_SPI 8
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 9 0 0 GIC_SPI 9
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 10 0 0 GIC_SPI 10
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 11 0 0 GIC_SPI 11
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 12 0 0 GIC_SPI 12
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 13 0 0 GIC_SPI 13
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 14 0 0 GIC_SPI 14
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 15 0 0 GIC_SPI 15
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 16 0 0 GIC_SPI 16
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 17 0 0 GIC_SPI 17
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 18 0 0 GIC_SPI 18
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 19 0 0 GIC_SPI 19
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 20 0 0 GIC_SPI 20
IRQ_TYPE_LEVEL_HIGH>,
- <0 0 21 0 0 GIC_SPI 21
IRQ_TYPE_LEVEL_HIGH>,
-
[PATCH AUTOSEL 5.7 058/388] ps3disk: use the default segment boundary
From: Emmanuel Nicolet
[ Upstream commit 720bc316690bd27dea9d71510b50f0cd698ffc32 ]
Since commit dcebd755926b ("block: use bio_for_each_bvec() to compute
multi-page bvec count"), the kernel will bug_on on the PS3 because
bio_split() is called with sectors == 0:
kernel BUG at block/bio.c:1853!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3
Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \
ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t
CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1
NIP: c027d0d0 LR: c027d0b0 CTR:
REGS: c135ae90 TRAP: 0700 Not tainted (5.3.0-rc4)
MSR: 80028032 CR: 44008240 XER: 2000
IRQMASK: 0
GPR00: c0289368 c135b120 c084a500 c4ff8300
GPR04: 0c00 c4c905e0 c4c905e0
GPR08: 0001
GPR12: c08ef000 003e 00080001
GPR16: 0100 0004
GPR20: c062fd7e 0001 0080
GPR24: c0781788 c135b350 0080 c4c905e0
GPR28: c135b348 c4ff8300 c4c9
NIP [c027d0d0] .bio_split+0x28/0xac
LR [c027d0b0] .bio_split+0x8/0xac
Call Trace:
[c135b120] [c027d130] .bio_split+0x88/0xac (unreliable)
[c135b1b0] [c0289368] .__blk_queue_split+0x11c/0x53c
[c135b2d0] [c028f614] .blk_mq_make_request+0x80/0x7d4
[c135b3d0] [c0283a8c] .generic_make_request+0x118/0x294
[c135b4b0] [c0283d34] .submit_bio+0x12c/0x174
[c135b580] [c0205a44] .mpage_bio_submit+0x3c/0x4c
[c135b600] [c0206184] .mpage_readpages+0xa4/0x184
[c135b750] [c01ff8fc] .blkdev_readpages+0x24/0x38
[c135b7c0] [c01589f0] .read_pages+0x6c/0x1a8
[c135b8b0] [c0158c74] .__do_page_cache_readahead+0x118/0x184
[c135b9b0] [c01591a8] .force_page_cache_readahead+0xe4/0xe8
[c135ba50] [c014fc24] .generic_file_read_iter+0x1d8/0x830
[c135bb50] [c01ffadc] .blkdev_read_iter+0x40/0x5c
[c135bbc0] [c01b9e00] .new_sync_read+0x144/0x1a0
[c135bcd0] [c01bc454] .vfs_read+0xa0/0x124
[c135bd70] [c01bc7a4] .ksys_read+0x70/0xd8
[c135be20] [c000a524] system_call+0x5c/0x70
Instruction dump:
7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0
7c7d1b78 79290fe0 7cc53378 69290001 <0b09> 81230028 7bca0020 7929ba62
[ end trace 313fec760f30aa1f ]---
The problem originates from setting the segment boundary of the
request queue to -1UL. This makes get_max_segment_size() return zero
when offset is zero, whatever the max segment size. The test with
BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows
to zero in the return statement.
Not setting the segment boundary and using the default
value (BLK_SEG_BOUNDARY_MASK) fixes the problem.
Signed-off-by: Emmanuel Nicolet
Signed-off-by: Geoff Levand
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.ge...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/block/ps3disk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/block/ps3disk.c b/drivers/block/ps3disk.c
index c5c6487a19d5..7b55811c2a81 100644
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -454,7 +454,6 @@ static int ps3disk_probe(struct ps3_system_bus_device *_dev)
queue->queuedata = dev;
blk_queue_max_hw_sectors(queue, dev->bounce_size >> 9);
- blk_queue_segment_boundary(queue, -1UL);
blk_queue_dma_alignment(queue, dev->blk_size-1);
blk_queue_logical_block_size(queue, dev->blk_size);
--
2.25.1
[PATCH AUTOSEL 5.7 057/388] PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register
From: Pali Rohár [ Upstream commit 90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ] Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-p...@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin --- drivers/pci/controller/pci-aardvark.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c index 2a20b649f40c..3a6d07dc0a38 100644 --- a/drivers/pci/controller/pci-aardvark.c +++ b/drivers/pci/controller/pci-aardvark.c @@ -353,10 +353,6 @@ static void advk_pcie_setup_hw(struct advk_pcie *pcie) advk_pcie_wait_for_link(pcie); - reg = PCIE_CORE_LINK_L0S_ENTRY | - (1 << PCIE_CORE_LINK_WIDTH_SHIFT); - advk_writel(pcie, reg, PCIE_CORE_LINK_CTRL_STAT_REG); - reg = advk_readl(pcie, PCIE_CORE_CMD_STATUS_REG); reg |= PCIE_CORE_CMD_MEM_ACCESS_EN | PCIE_CORE_CMD_IO_ACCESS_EN | -- 2.25.1
[PATCH AUTOSEL 5.7 053/388] pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2
From: Lars Povlsen
[ Upstream commit 0b47afc65453a70bc521e251138418056f65793f ]
This fixes a problem with using the GPIO as an interrupt on Jaguar2
(and similar), as the register layout of the platforms with 64 GPIO's
are pairwise, such that the original offset must be multiplied with
the platform stride.
Fixes: da801ab56ad8 pinctrl: ocelot: add MSCC Jaguar2 support.
Reviewed-by: Alexandre Belloni
Signed-off-by: Lars Povlsen
Link:
https://lore.kernel.org/r/20200513125532.24585-4-lars.povl...@microchip.com
Signed-off-by: Linus Walleij
Signed-off-by: Sasha Levin
---
drivers/pinctrl/pinctrl-ocelot.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index ed8eac6c1494..4b99922d6c7e 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -714,11 +714,12 @@ static void ocelot_irq_handler(struct irq_desc *desc)
struct irq_chip *parent_chip = irq_desc_get_chip(desc);
struct gpio_chip *chip = irq_desc_get_handler_data(desc);
struct ocelot_pinctrl *info = gpiochip_get_data(chip);
+ unsigned int id_reg = OCELOT_GPIO_INTR_IDENT * info->stride;
unsigned int reg = 0, irq, i;
unsigned long irqs;
for (i = 0; i < info->stride; i++) {
- regmap_read(info->map, OCELOT_GPIO_INTR_IDENT + 4 * i, );
+ regmap_read(info->map, id_reg + 4 * i, );
if (!reg)
continue;
--
2.25.1
[PATCH AUTOSEL 5.7 055/388] ASoC: SOF: Do nothing when DSP PM callbacks are not set
From: Daniel Baluta [ Upstream commit c26fde3b15ed41f5f452f1da727795f787833287 ] This provides a better separation between runtime and PM sleep callbacks. Only do nothing if given runtime flag is set and calback is not set. With the current implementation, if PM sleep callback is set but runtime callback is not set then at runtime resume we reload the firmware even if we do not support runtime resume callback. Signed-off-by: Daniel Baluta Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20200515135958.17511-2-kai.vehma...@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin --- sound/soc/sof/pm.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/pm.c b/sound/soc/sof/pm.c index c410822d9920..01d83ddc16ba 100644 --- a/sound/soc/sof/pm.c +++ b/sound/soc/sof/pm.c @@ -90,7 +90,10 @@ static int sof_resume(struct device *dev, bool runtime_resume) int ret; /* do nothing if dsp resume callbacks are not set */ - if (!sof_ops(sdev)->resume || !sof_ops(sdev)->runtime_resume) + if (!runtime_resume && !sof_ops(sdev)->resume) + return 0; + + if (runtime_resume && !sof_ops(sdev)->runtime_resume) return 0; /* DSP was never successfully started, nothing to resume */ @@ -175,7 +178,10 @@ static int sof_suspend(struct device *dev, bool runtime_suspend) int ret; /* do nothing if dsp suspend callback is not set */ - if (!sof_ops(sdev)->suspend) + if (!runtime_suspend && !sof_ops(sdev)->suspend) + return 0; + + if (runtime_suspend && !sof_ops(sdev)->runtime_suspend) return 0; if (sdev->fw_state != SOF_FW_BOOT_COMPLETE) -- 2.25.1
[PATCH AUTOSEL 5.7 051/388] RDMA/uverbs: Fix create WQ to use the given user handle
From: Yishai Hadas
[ Upstream commit dbd67252869ba58d086edfa14113e10f8059b97e ]
Fix create WQ to use the given user handle, in addition dropped some
duplicated code from this flow.
Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema")
Fixes: f213c0527210 ("IB/uverbs: Add WQ support")
Link: https://lore.kernel.org/r/20200506082444.14502-9-l...@kernel.org
Signed-off-by: Yishai Hadas
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/core/uverbs_cmd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_cmd.c
b/drivers/infiniband/core/uverbs_cmd.c
index 060b4ebbd2ba..d6e9cc94dd90 100644
--- a/drivers/infiniband/core/uverbs_cmd.c
+++ b/drivers/infiniband/core/uverbs_cmd.c
@@ -2959,6 +2959,7 @@ static int ib_uverbs_ex_create_wq(struct
uverbs_attr_bundle *attrs)
wq_init_attr.event_handler = ib_uverbs_wq_event_handler;
wq_init_attr.create_flags = cmd.create_flags;
INIT_LIST_HEAD(>uevent.event_list);
+ obj->uevent.uobject.user_handle = cmd.user_handle;
wq = pd->device->ops.create_wq(pd, _init_attr, >driver_udata);
if (IS_ERR(wq)) {
@@ -2976,8 +2977,6 @@ static int ib_uverbs_ex_create_wq(struct
uverbs_attr_bundle *attrs)
atomic_set(>usecnt, 0);
atomic_inc(>usecnt);
atomic_inc(>usecnt);
- wq->uobject = obj;
- obj->uevent.uobject.object = wq;
memset(, 0, sizeof(resp));
resp.wq_handle = obj->uevent.uobject.id;
--
2.25.1
[PATCH AUTOSEL 5.7 049/388] arm64: dts: armada-3720-turris-mox: fix SFP binding
From: Marek Behún
[ Upstream commit c2671acbbbd822ef077cc168991e0a7dbe2172c9 ]
The sfp compatible should be 'sff,sfp', not 'sff,sfp+'. We used patched
kernel where the latter was working.
Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Marek Behún
Cc: Gregory CLEMENT
Signed-off-by: Gregory CLEMENT
Signed-off-by: Sasha Levin
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
index 47fee66c70cb..0e0491ca2930 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts
@@ -95,7 +95,7 @@ sdhci1_pwrseq: sdhci1-pwrseq {
};
sfp: sfp {
- compatible = "sff,sfp+";
+ compatible = "sff,sfp";
i2c-bus = <>;
los-gpio = <_sfp 0 GPIO_ACTIVE_HIGH>;
tx-fault-gpio = <_sfp 1 GPIO_ACTIVE_HIGH>;
--
2.25.1
[PATCH AUTOSEL 5.7 059/388] arm64: dts: fvp/juno: Fix node address fields
From: Andre Przywara
[ Upstream commit bb5cce12ac717c7462217cd493ed701d12d6dbce ]
The Arm Ltd. boards were using an outdated address convention in the DT
node names, by separating the high from the low 32-bits of an address by
a comma.
Remove the comma from the node name suffix to be DT spec compliant.
Link: https://lore.kernel.org/r/20200513103016.130417-3-andre.przyw...@arm.com
Signed-off-by: Andre Przywara
Signed-off-by: Sudeep Holla
Signed-off-by: Sasha Levin
---
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 10 +-
arch/arm64/boot/dts/arm/foundation-v8.dtsi | 4 ++--
arch/arm64/boot/dts/arm/juno-motherboard.dtsi| 6 +++---
arch/arm64/boot/dts/arm/rtsm_ve-motherboard-rs2.dtsi | 2 +-
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 6 +++---
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
index 5c183483ec3b..8010cdcdb37a 100644
--- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
+++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
@@ -31,7 +31,7 @@ motherboard {
#interrupt-cells = <1>;
ranges;
- nor_flash: flash@0, {
+ nor_flash: flash@0 {
compatible = "arm,vexpress-flash", "cfi-flash";
reg = <0 0x 0x0400>,
<4 0x 0x0400>;
@@ -41,13 +41,13 @@ partitions {
};
};
- psram@1, {
+ psram@1 {
compatible = "arm,vexpress-psram", "mtd-ram";
reg = <1 0x 0x0200>;
bank-width = <4>;
};
- ethernet@2,0200 {
+ ethernet@20200 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x0200 0x1>;
interrupts = <15>;
@@ -59,14 +59,14 @@ ethernet@2,0200 {
vddvario-supply = <_fixed_3v3>;
};
- usb@2,0300 {
+ usb@20300 {
compatible = "nxp,usb-isp1761";
reg = <2 0x0300 0x2>;
interrupts = <16>;
port1-otg;
};
- iofpga@3, {
+ iofpga@3 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
index 60ec37d6c9d3..e2da63f78298 100644
--- a/arch/arm64/boot/dts/arm/foundation-v8.dtsi
+++ b/arch/arm64/boot/dts/arm/foundation-v8.dtsi
@@ -151,7 +151,7 @@ bus@800 {
<0 0 41 0 GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42 0 GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
- ethernet@2,0200 {
+ ethernet@20200 {
compatible = "smsc,lan91c111";
reg = <2 0x0200 0x1>;
interrupts = <15>;
@@ -178,7 +178,7 @@ v2m_refclk32khz: refclk32khz {
clock-output-names = "v2m:refclk32khz";
};
- iofpga@3, {
+ iofpga@3 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index e3983ded3c3c..d5cefddde08c 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -103,7 +103,7 @@ nmi-button {
};
};
- flash@0, {
+ flash@0 {
/* 2 * 32MiB NOR Flash memory mounted on CS0 */
compatible = "arm,vexpress-flash", "cfi-flash";
reg = <0 0x 0x0400>;
@@ -120,7 +120,7 @@ partitions {
};
};
- ethernet@2, {
+ ethernet@2 {
compatible = "smsc,lan9118", "smsc,lan9115";
reg = <2 0x 0x1>;
interrupts = <3>;
@@ -133,7 +133,7 @@ ethernet@2, {
[PATCH AUTOSEL 5.7 047/388] dm mpath: switch paths in dm_blk_ioctl() code path
From: Martin Wilck
[ Upstream commit 2361ae595352dec015d14292f1b539242d8446d6 ]
SCSI LUN passthrough code such as qemu's "scsi-block" device model
pass every IO to the host via SG_IO ioctls. Currently, dm-multipath
calls choose_pgpath() only in the block IO code path, not in the ioctl
code path (unless current_pgpath is NULL). This has the effect that no
path switching and thus no load balancing is done for SCSI-passthrough
IO, unless the active path fails.
Fix this by using the same logic in multipath_prepare_ioctl() as in
multipath_clone_and_map().
Note: The allegedly best path selection algorithm, service-time,
still wouldn't work perfectly, because the io size of the current
request is always set to 0. Changing that for the IO passthrough
case would require the ioctl cmd and arg to be passed to dm's
prepare_ioctl() method.
Signed-off-by: Martin Wilck
Reviewed-by: Hannes Reinecke
Signed-off-by: Mike Snitzer
Signed-off-by: Sasha Levin
---
drivers/md/dm-mpath.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-mpath.c b/drivers/md/dm-mpath.c
index 3e500098132f..e0c800cf87a9 100644
--- a/drivers/md/dm-mpath.c
+++ b/drivers/md/dm-mpath.c
@@ -1918,7 +1918,7 @@ static int multipath_prepare_ioctl(struct dm_target *ti,
int r;
current_pgpath = READ_ONCE(m->current_pgpath);
- if (!current_pgpath)
+ if (!current_pgpath || !test_bit(MPATHF_QUEUE_IO, >flags))
current_pgpath = choose_pgpath(m, 0);
if (current_pgpath) {
--
2.25.1
[PATCH AUTOSEL 5.7 052/388] RDMA/srpt: Fix disabling device management
From: Kamal Heib
[ Upstream commit 23bbd5818e2b0d265aa1835e66f5055f63a8fa4c ]
Avoid disabling device management for devices that don't support
Management datagrams (MADs) by checking if the "mad_agent" pointer is
initialized before calling ib_modify_port, also fix the error flow in
srpt_refresh_port() to disable device management if
ib_register_mad_agent() fail.
Fixes: 09f8a1486dca ("RDMA/srpt: Fix handling of SR-IOV and iWARP ports")
Link: https://lore.kernel.org/r/20200514114720.141139-1-kamalhe...@gmail.com
Signed-off-by: Kamal Heib
Reviewed-by: Bart Van Assche
Signed-off-by: Jason Gunthorpe
Signed-off-by: Sasha Levin
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c
b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 98552749d71c..fcf982c60db6 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -610,6 +610,11 @@ static int srpt_refresh_port(struct srpt_port *sport)
dev_name(>sdev->device->dev), sport->port,
PTR_ERR(sport->mad_agent));
sport->mad_agent = NULL;
+ memset(_modify, 0, sizeof(port_modify));
+ port_modify.clr_port_cap_mask = IB_PORT_DEVICE_MGMT_SUP;
+ ib_modify_port(sport->sdev->device, sport->port, 0,
+ _modify);
+
}
}
@@ -633,9 +638,8 @@ static void srpt_unregister_mad_agent(struct srpt_device
*sdev)
for (i = 1; i <= sdev->device->phys_port_cnt; i++) {
sport = >port[i - 1];
WARN_ON(sport->port != i);
- if (ib_modify_port(sdev->device, i, 0, _modify) < 0)
- pr_err("disabling MAD processing failed.\n");
if (sport->mad_agent) {
+ ib_modify_port(sdev->device, i, 0, _modify);
ib_unregister_mad_agent(sport->mad_agent);
sport->mad_agent = NULL;
}
--
2.25.1
[PATCH AUTOSEL 5.7 039/388] clk: samsung: Mark top ISP and CAM clocks on Exynos542x as critical
From: Marek Szyprowski
[ Upstream commit e47bd937e602bb4379546095d1bd0b9871fa60c2 ]
The TOP 'aclk*_isp', 'aclk550_cam', 'gscl_wa' and 'gscl_wb' clocks must
be kept enabled all the time to allow proper access to power management
control for the ISP and CAM power domains. The last two clocks, although
related to GScaler device and GSCL power domain, provides also the
I_WRAP_CLK signal to MIPI CSIS0/1 devices, which are a part of CAM power
domain and are needed for proper power on/off sequence.
Currently there are no drivers for the devices, which are part of CAM and
ISP power domains yet. This patch only fixes the race between disabling
the unused power domains and disabling unused clocks, which randomly
resulted in the following error during boot:
Power domain CAM disable failed
Power domain ISP disable failed
Fixes: 318fa46cc60d ("clk/samsung: exynos542x: mark some clocks as critical")
Signed-off-by: Marek Szyprowski
Acked-by: Chanwoo Choi
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Sasha Levin
---
drivers/clk/samsung/clk-exynos5420.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index c9e5a1fb6653..edb2363c735a 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -540,7 +540,7 @@ static const struct samsung_div_clock exynos5800_div_clks[]
__initconst = {
static const struct samsung_gate_clock exynos5800_gate_clks[] __initconst = {
GATE(CLK_ACLK550_CAM, "aclk550_cam", "mout_user_aclk550_cam",
- GATE_BUS_TOP, 24, 0, 0),
+ GATE_BUS_TOP, 24, CLK_IS_CRITICAL, 0),
GATE(CLK_ACLK432_SCALER, "aclk432_scaler", "mout_user_aclk432_scaler",
GATE_BUS_TOP, 27, CLK_IS_CRITICAL, 0),
};
@@ -943,25 +943,25 @@ static const struct samsung_gate_clock
exynos5x_gate_clks[] __initconst = {
GATE(0, "aclk300_jpeg", "mout_user_aclk300_jpeg",
GATE_BUS_TOP, 4, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk333_432_isp0", "mout_user_aclk333_432_isp0",
- GATE_BUS_TOP, 5, 0, 0),
+ GATE_BUS_TOP, 5, CLK_IS_CRITICAL, 0),
GATE(0, "aclk300_gscl", "mout_user_aclk300_gscl",
GATE_BUS_TOP, 6, CLK_IS_CRITICAL, 0),
GATE(0, "aclk333_432_gscl", "mout_user_aclk333_432_gscl",
GATE_BUS_TOP, 7, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk333_432_isp", "mout_user_aclk333_432_isp",
- GATE_BUS_TOP, 8, 0, 0),
+ GATE_BUS_TOP, 8, CLK_IS_CRITICAL, 0),
GATE(CLK_PCLK66_GPIO, "pclk66_gpio", "mout_user_pclk66_gpio",
GATE_BUS_TOP, 9, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk66_psgen", "mout_user_aclk66_psgen",
GATE_BUS_TOP, 10, CLK_IGNORE_UNUSED, 0),
GATE(0, "aclk266_isp", "mout_user_aclk266_isp",
- GATE_BUS_TOP, 13, 0, 0),
+ GATE_BUS_TOP, 13, CLK_IS_CRITICAL, 0),
GATE(0, "aclk166", "mout_user_aclk166",
GATE_BUS_TOP, 14, CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK333, "aclk333", "mout_user_aclk333",
GATE_BUS_TOP, 15, CLK_IS_CRITICAL, 0),
GATE(0, "aclk400_isp", "mout_user_aclk400_isp",
- GATE_BUS_TOP, 16, 0, 0),
+ GATE_BUS_TOP, 16, CLK_IS_CRITICAL, 0),
GATE(0, "aclk400_mscl", "mout_user_aclk400_mscl",
GATE_BUS_TOP, 17, CLK_IS_CRITICAL, 0),
GATE(0, "aclk200_disp1", "mout_user_aclk200_disp1",
@@ -1161,8 +1161,10 @@ static const struct samsung_gate_clock
exynos5x_gate_clks[] __initconst = {
GATE_IP_GSCL1, 3, 0, 0),
GATE(CLK_SMMU_FIMCL1, "smmu_fimcl1", "dout_gscl_blk_333",
GATE_IP_GSCL1, 4, 0, 0),
- GATE(CLK_GSCL_WA, "gscl_wa", "sclk_gscl_wa", GATE_IP_GSCL1, 12, 0, 0),
- GATE(CLK_GSCL_WB, "gscl_wb", "sclk_gscl_wb", GATE_IP_GSCL1, 13, 0, 0),
+ GATE(CLK_GSCL_WA, "gscl_wa", "sclk_gscl_wa", GATE_IP_GSCL1, 12,
+ CLK_IS_CRITICAL, 0),
+ GATE(CLK_GSCL_WB, "gscl_wb", "sclk_gscl_wb", GATE_IP_GSCL1, 13,
+ CLK_IS_CRITICAL, 0),
GATE(CLK_SMMU_FIMCL3, "smmu_fimcl3,", "dout_gscl_blk_333",
GATE_IP_GSCL1, 16, 0, 0),
GATE(CLK_FIMC_LITE3, "fimc_lite3", "aclk333_432_gscl",
--
2.25.1
[PATCH AUTOSEL 5.7 037/388] i2c: pxa: clear all master action bits in i2c_pxa_stop_message()
From: Russell King
[ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ]
If we timeout during a message transfer, the control register may
contain bits that cause an action to be set. Read-modify-writing the
register leaving these bits set may trigger the hardware to attempt
one of these actions unintentionally.
Always clear these bits when cleaning up after a message or after
a timeout.
Signed-off-by: Russell King
Signed-off-by: Wolfram Sang
Signed-off-by: Sasha Levin
---
drivers/i2c/busses/i2c-pxa.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 466e4f681d7a..30a6e07212a4 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -747,11 +747,9 @@ static inline void i2c_pxa_stop_message(struct pxa_i2c
*i2c)
{
u32 icr;
- /*
-* Clear the STOP and ACK flags
-*/
+ /* Clear the START, STOP, ACK, TB and MA flags */
icr = readl(_ICR(i2c));
- icr &= ~(ICR_STOP | ICR_ACKNAK);
+ icr &= ~(ICR_START | ICR_STOP | ICR_ACKNAK | ICR_TB | ICR_MA);
writel(icr, _ICR(i2c));
}
--
2.25.1
[PATCH AUTOSEL 5.7 067/388] m68k/PCI: Fix a memory leak in an error handling path
From: Christophe JAILLET
[ Upstream commit c3f4ec050f56eeab7c1f290321f9b762c95bd332 ]
If 'ioremap' fails, we must free 'bridge', as done in other error handling
path bellow.
Fixes: 19cc4c843f40 ("m68k/PCI: Replace pci_fixup_irqs() call with host bridge
IRQ mapping hooks")
Signed-off-by: Christophe JAILLET
Reviewed-by: Geert Uytterhoeven
Signed-off-by: Greg Ungerer
Signed-off-by: Sasha Levin
---
arch/m68k/coldfire/pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/m68k/coldfire/pci.c b/arch/m68k/coldfire/pci.c
index 62b0eb6cf69a..84eab0f5e00a 100644
--- a/arch/m68k/coldfire/pci.c
+++ b/arch/m68k/coldfire/pci.c
@@ -216,8 +216,10 @@ static int __init mcf_pci_init(void)
/* Keep a virtual mapping to IO/config space active */
iospace = (unsigned long) ioremap(PCI_IO_PA, PCI_IO_SIZE);
- if (iospace == 0)
+ if (iospace == 0) {
+ pci_free_host_bridge(bridge);
return -ENODEV;
+ }
pr_info("Coldfire: PCI IO/config window mapped to 0x%x\n",
(u32) iospace);
--
2.25.1
[PATCH AUTOSEL 5.7 069/388] usb: cdns3: Fix runtime PM imbalance on error
From: Dinghao Liu
[ Upstream commit e5b913496099527abe46e175e5e2c844367bded0 ]
pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.
Reviewed-by: Peter Chen
Signed-off-by: Dinghao Liu
Signed-off-by: Felipe Balbi
Signed-off-by: Sasha Levin
---
drivers/usb/cdns3/cdns3-ti.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 5685ba11480b..e701ab56b0a7 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -138,7 +138,7 @@ static int cdns_ti_probe(struct platform_device *pdev)
error = pm_runtime_get_sync(dev);
if (error < 0) {
dev_err(dev, "pm_runtime_get_sync failed: %d\n", error);
- goto err_get;
+ goto err;
}
/* assert RESET */
@@ -185,7 +185,6 @@ static int cdns_ti_probe(struct platform_device *pdev)
err:
pm_runtime_put_sync(data->dev);
-err_get:
pm_runtime_disable(data->dev);
return error;
--
2.25.1
