Re: [PATCH v1 2/9] extcon: extcon-ptn5150: Switch to GENMASK() for VBUS detection macro

[Krzysztof Kozlowski]

On Tue, Aug 18, 2020 at 02:57:20PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Switch to GENMASK() for VBUS detection macro.
> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

This is too simple change, should be squashed with 1, 3, 4 and 5.

There is no point to split each change a define to use BIT or GENMASK.

Best regards,
Krzysztof

> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 5d9a8767646b..c816a6c1e05c 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -42,9 +42,7 @@ enum ptn5150_reg {
>  #define PTN5150_REG_CC_PORT_ATTACHMENT_MASK  \
>   (0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
>  
> -#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT  7
> -#define PTN5150_REG_CC_VBUS_DETECTION_MASK   \
> - (0x1 << PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
> +#define PTN5150_REG_CC_VBUS_DETECTIONBIT(7)
>  
>  #define PTN5150_REG_INT_CABLE_ATTACH_SHIFT   0
>  #define PTN5150_REG_INT_CABLE_ATTACH_MASK\
> @@ -130,9 +128,8 @@ static void ptn5150_irq_work(struct work_struct *work)
>   case PTN5150_UFP_ATTACHED:
>   extcon_set_state_sync(info->edev, EXTCON_USB,
>   false);
> - vbus = ((reg_data &
> - PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
> - PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
> + vbus = FIELD_GET(PTN5150_REG_CC_VBUS_DETECTION,
> +  reg_data);
>   if (vbus)
>   gpiod_set_value(info->vbus_gpiod, 0);
>   else
> -- 
> 2.11.0
> 

Re: [PATCH v1 3/9] extcon: extcon-ptn5150: Switch to BIT() macro for cable attach

[Krzysztof Kozlowski]

On Tue, Aug 18, 2020 at 02:57:21PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Switch to BIT() macro for the cable attach.

Squash it.

> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index c816a6c1e05c..fab862d9aad8 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -44,9 +44,7 @@ enum ptn5150_reg {
>  
>  #define PTN5150_REG_CC_VBUS_DETECTIONBIT(7)
>  
> -#define PTN5150_REG_INT_CABLE_ATTACH_SHIFT   0
> -#define PTN5150_REG_INT_CABLE_ATTACH_MASK\
> - (0x1 << PTN5150_REG_INT_CABLE_ATTACH_SHIFT)
> +#define PTN5150_REG_INT_CABLE_ATTACH_MASKBIT(0)
>  
>  #define PTN5150_REG_INT_CABLE_DETACH_SHIFT   1
>  #define PTN5150_REG_INT_CABLE_DETACH_MASK\
> -- 
> 2.11.0
> 

[PATCH 18/19] z2ram: use separate gendisk for the different modes

[Christoph Hellwig]

Use separate gendisks (which share a tag_set) for the different operating
modes instead of redirecting the gendisk lookup using a probe callback.
This avoids potential problems with aliased block_device instances and
will eventually allow for removing the blk_register_region framework.

Signed-off-by: Christoph Hellwig 
---
 drivers/block/z2ram.c | 100 --
 1 file changed, 58 insertions(+), 42 deletions(-)

diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
index 566c653399d8d3..2bf059ba95603c 100644
--- a/drivers/block/z2ram.c
+++ b/drivers/block/z2ram.c
@@ -63,7 +63,7 @@ static int current_device = -1;
 
 static DEFINE_SPINLOCK(z2ram_lock);
 
-static struct gendisk *z2ram_gendisk;
+static struct gendisk *z2ram_gendisk[Z2MINOR_COUNT];
 
 static blk_status_t z2_queue_rq(struct blk_mq_hw_ctx *hctx,
const struct blk_mq_queue_data *bd)
@@ -281,7 +281,7 @@ static int z2_open(struct block_device *bdev, fmode_t mode)
 
current_device = device;
z2ram_size <<= Z2RAM_CHUNKSHIFT;
-   set_capacity(z2ram_gendisk, z2ram_size >> 9);
+   set_capacity(z2ram_gendisk[device], z2ram_size >> 9);
}
 
mutex_unlock(&z2ram_mutex);
@@ -313,71 +313,87 @@ static const struct block_device_operations z2_fops = {
.release = z2_release,
 };
 
-static struct kobject *z2_find(dev_t dev, int *part, void *data)
-{
-   *part = 0;
-   return get_disk_and_module(z2ram_gendisk);
-}
-
-static struct request_queue *z2_queue;
 static struct blk_mq_tag_set tag_set;
 
 static const struct blk_mq_ops z2_mq_ops = {
.queue_rq = z2_queue_rq,
 };
 
+static int z2ram_register_disk(int minor)
+{
+   struct request_queue *q;
+   struct gendisk *disk;
+
+   disk = alloc_disk(1);
+   if (!disk)
+   return -ENOMEM;
+
+   q = blk_mq_init_queue(&tag_set);
+   if (IS_ERR(q)) {
+   put_disk(disk);
+   return PTR_ERR(q);
+   }
+
+   disk->major = Z2RAM_MAJOR;
+   disk->first_minor = minor;
+   disk->fops = &z2_fops;
+   if (minor)
+   sprintf(disk->disk_name, "z2ram%d", minor);
+   else
+   sprintf(disk->disk_name, "z2ram");
+   disk->queue = q;
+
+   z2ram_gendisk[minor] = disk;
+   add_disk(disk);
+   return 0;
+}
+
 static int __init z2_init(void)
 {
-   int ret;
+   int ret, i;
 
if (!MACH_IS_AMIGA)
return -ENODEV;
 
-   ret = -EBUSY;
if (register_blkdev(Z2RAM_MAJOR, DEVICE_NAME))
-   goto err;
-
-   ret = -ENOMEM;
-   z2ram_gendisk = alloc_disk(1);
-   if (!z2ram_gendisk)
-   goto out_disk;
-
-   z2_queue = blk_mq_init_sq_queue(&tag_set, &z2_mq_ops, 16,
-   BLK_MQ_F_SHOULD_MERGE);
-   if (IS_ERR(z2_queue)) {
-   ret = PTR_ERR(z2_queue);
-   z2_queue = NULL;
-   goto out_queue;
+   return -EBUSY;
+
+   tag_set.ops = &z2_mq_ops;
+   tag_set.nr_hw_queues = 1;
+   tag_set.nr_maps = 1;
+   tag_set.queue_depth = 16;
+   tag_set.numa_node = NUMA_NO_NODE;
+   tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
+   ret = blk_mq_alloc_tag_set(&tag_set);
+   if (ret)
+   goto out_unregister_blkdev;
+
+   for (i = 0; i < Z2MINOR_COUNT; i++) {
+   ret = z2ram_register_disk(i);
+   if (ret && i == 0)
+   goto out_free_tagset;
}
 
-   z2ram_gendisk->major = Z2RAM_MAJOR;
-   z2ram_gendisk->first_minor = 0;
-   z2ram_gendisk->fops = &z2_fops;
-   sprintf(z2ram_gendisk->disk_name, "z2ram");
-
-   z2ram_gendisk->queue = z2_queue;
-   add_disk(z2ram_gendisk);
-   blk_register_region(MKDEV(Z2RAM_MAJOR, 0), Z2MINOR_COUNT, THIS_MODULE,
-   z2_find, NULL, NULL);
-
return 0;
 
-out_queue:
-   put_disk(z2ram_gendisk);
-out_disk:
+out_free_tagset:
+   blk_mq_free_tag_set(&tag_set);
+out_unregister_blkdev:
unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME);
-err:
return ret;
 }
 
 static void __exit z2_exit(void)
 {
int i, j;
-   blk_unregister_region(MKDEV(Z2RAM_MAJOR, 0), Z2MINOR_COUNT);
+
unregister_blkdev(Z2RAM_MAJOR, DEVICE_NAME);
-   del_gendisk(z2ram_gendisk);
-   put_disk(z2ram_gendisk);
-   blk_cleanup_queue(z2_queue);
+
+   for (i = 0; i < Z2MINOR_COUNT; i++) {
+   del_gendisk(z2ram_gendisk[i]);
+   blk_cleanup_queue(z2ram_gendisk[i]->queue);
+   put_disk(z2ram_gendisk[i]);
+   }
blk_mq_free_tag_set(&tag_set);
 
if (current_device != -1) {
-- 
2.28.0

[PATCH 15/19] amiflop: use separate gendisks for Amiga vs MS-DOS mode

[Christoph Hellwig]

Use separate gendisks (which share a tag_set) for the native Amgiga vs
the MS-DOS mode instead of redirecting the gendisk lookup using a probe
callback.  This avoids potential problems with aliased block_device
instances and will eventually allow for removing the blk_register_region
framework.

Signed-off-by: Christoph Hellwig 
---
 drivers/block/amiflop.c | 98 +++--
 1 file changed, 55 insertions(+), 43 deletions(-)

diff --git a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 226219da3da6a7..de2bad8d1512f2 100644
--- a/drivers/block/amiflop.c
+++ b/drivers/block/amiflop.c
@@ -201,7 +201,7 @@ struct amiga_floppy_struct {
int busy;   /* true when drive is active */
int dirty;  /* true when trackbuf is not on disk */
int status; /* current error code for unit */
-   struct gendisk *gendisk;
+   struct gendisk *gendisk[2];
struct blk_mq_tag_set tag_set;
 };
 
@@ -1669,6 +1669,11 @@ static int floppy_open(struct block_device *bdev, 
fmode_t mode)
return -EBUSY;
}
 
+   if (unit[drive].type->code == FD_NODRIVE) {
+   mutex_unlock(&amiflop_mutex);
+   return -ENXIO;
+   }
+
if (mode & (FMODE_READ|FMODE_WRITE)) {
check_disk_change(bdev);
if (mode & FMODE_WRITE) {
@@ -1695,7 +1700,7 @@ static int floppy_open(struct block_device *bdev, fmode_t 
mode)
unit[drive].dtype=&data_types[system];
unit[drive].blocks=unit[drive].type->heads*unit[drive].type->tracks*
data_types[system].sects*unit[drive].type->sect_mult;
-   set_capacity(unit[drive].gendisk, unit[drive].blocks);
+   set_capacity(unit[drive].gendisk[system], unit[drive].blocks);
 
printk(KERN_INFO "fd%d: accessing %s-disk with %s-layout\n",drive,
   unit[drive].type->name, data_types[system].name);
@@ -1772,36 +1777,68 @@ static const struct blk_mq_ops amiflop_mq_ops = {
.queue_rq = amiflop_queue_rq,
 };
 
-static struct gendisk *fd_alloc_disk(int drive)
+static int fd_alloc_disk(int drive, int system)
 {
struct gendisk *disk;
 
disk = alloc_disk(1);
if (!disk)
goto out;
-
-   disk->queue = blk_mq_init_sq_queue(&unit[drive].tag_set, 
&amiflop_mq_ops,
-   2, BLK_MQ_F_SHOULD_MERGE);
-   if (IS_ERR(disk->queue)) {
-   disk->queue = NULL;
+   disk->queue = blk_mq_init_queue(&unit[drive].tag_set);
+   if (IS_ERR(disk->queue))
goto out_put_disk;
-   }
 
+   disk->major = FLOPPY_MAJOR;
+   disk->first_minor = drive + system;
+   disk->fops = &floppy_fops;
+   disk->events = DISK_EVENT_MEDIA_CHANGE;
+   if (system)
+   sprintf(disk->disk_name, "fd%d_msdos", drive);
+   else
+   sprintf(disk->disk_name, "fd%d", drive);
+   disk->private_data = &unit[drive];
+   set_capacity(disk, 880 * 2);
+
+   unit[drive].gendisk[system] = disk;
+   add_disk(disk);
+   return 0;
+
+out_put_disk:
+   disk->queue = NULL;
+   put_disk(disk);
+out:
+   return -ENOMEM;
+}
+
+static int fd_alloc_drive(int drive)
+{
unit[drive].trackbuf = kmalloc(FLOPPY_MAX_SECTORS * 512, GFP_KERNEL);
if (!unit[drive].trackbuf)
-   goto out_cleanup_queue;
+   goto out;
 
-   return disk;
+   memset(&unit[drive].tag_set, 0, sizeof(unit[drive].tag_set));
+   unit[drive].tag_set.ops = &amiflop_mq_ops;
+   unit[drive].tag_set.nr_hw_queues = 1;
+   unit[drive].tag_set.nr_maps = 1;
+   unit[drive].tag_set.queue_depth = 2;
+   unit[drive].tag_set.numa_node = NUMA_NO_NODE;
+   unit[drive].tag_set.flags = BLK_MQ_F_SHOULD_MERGE;
+   if (blk_mq_alloc_tag_set(&unit[drive].tag_set))
+   goto out_cleanup_trackbuf;
 
-out_cleanup_queue:
-   blk_cleanup_queue(disk->queue);
-   disk->queue = NULL;
+   pr_cont(" fd%d", drive);
+
+   if (fd_alloc_disk(drive, 0) || fd_alloc_disk(drive, 1))
+   goto out_cleanup_tagset;
+   return 0;
+
+out_cleanup_tagset:
blk_mq_free_tag_set(&unit[drive].tag_set);
-out_put_disk:
-   put_disk(disk);
+out_cleanup_trackbuf:
+   kfree(unit[drive].trackbuf);
 out:
unit[drive].type->code = FD_NODRIVE;
-   return NULL;
+   return -ENOMEM;
 }
 
 static int __init fd_probe_drives(void)
@@ -1812,29 +1849,16 @@ static int __init fd_probe_drives(void)
drives=0;
nomem=0;
for(drive=0;drivecode == FD_NODRIVE)
continue;
 
-   disk = fd_alloc_disk(drive);
-   if (!disk) {
+   if (fd_alloc_drive(drive) < 0) {
pr_cont(" no mem for fd%d", drive);
nomem = 1;
continue;
}
-   u

[PATCH 19/19] block: switch gendisk lookup to a simple xarray

[Christoph Hellwig]

Now that bdev_map is only used for finding gendisks, we can use
a simple xarray instead of the regions tracking structure for it.

Signed-off-by: Christoph Hellwig 
---
 block/genhd.c | 210 --
 include/linux/genhd.h |   7 --
 2 files changed, 38 insertions(+), 179 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 4cbeff3ec1ef5a..80afacaf15f740 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -27,15 +27,7 @@
 
 static struct kobject *block_depr;
 
-struct bdev_map {
-   struct bdev_map *next;
-   dev_t dev;
-   unsigned long range;
-   struct module *owner;
-   struct kobject *(*probe)(dev_t, int *, void *);
-   int (*lock)(dev_t, void *);
-   void *data;
-} *bdev_map[255];
+static DEFINE_XARRAY(bdev_map);
 static DEFINE_MUTEX(bdev_map_lock);
 
 /* for extended dynamic devt allocation, currently only one major is used */
@@ -649,85 +641,26 @@ static char *bdevt_str(dev_t devt, char *buf)
return buf;
 }
 
-/*
- * Register device numbers dev..(dev+range-1)
- * range must be nonzero
- * The hash chain is sorted on range, so that subranges can override.
- */
-void blk_register_region(dev_t devt, unsigned long range, struct module 
*module,
-struct kobject *(*probe)(dev_t, int *, void *),
-int (*lock)(dev_t, void *), void *data)
-{
-   unsigned n = MAJOR(devt + range - 1) - MAJOR(devt) + 1;
-   unsigned index = MAJOR(devt);
-   unsigned i;
-   struct bdev_map *p;
-
-   n = min(n, 255u);
-   p = kmalloc_array(n, sizeof(struct bdev_map), GFP_KERNEL);
-   if (p == NULL)
-   return;
-
-   for (i = 0; i < n; i++, p++) {
-   p->owner = module;
-   p->probe = probe;
-   p->lock = lock;
-   p->dev = devt;
-   p->range = range;
-   p->data = data;
-   }
-
-   mutex_lock(&bdev_map_lock);
-   for (i = 0, p -= n; i < n; i++, p++, index++) {
-   struct bdev_map **s = &bdev_map[index % 255];
-   while (*s && (*s)->range < range)
-   s = &(*s)->next;
-   p->next = *s;
-   *s = p;
-   }
-   mutex_unlock(&bdev_map_lock);
-}
-EXPORT_SYMBOL(blk_register_region);
-
-void blk_unregister_region(dev_t devt, unsigned long range)
+static void blk_register_region(struct gendisk *disk)
 {
-   unsigned n = MAJOR(devt + range - 1) - MAJOR(devt) + 1;
-   unsigned index = MAJOR(devt);
-   unsigned i;
-   struct bdev_map *found = NULL;
+   int i;
 
mutex_lock(&bdev_map_lock);
-   for (i = 0; i < min(n, 255u); i++, index++) {
-   struct bdev_map **s;
-   for (s = &bdev_map[index % 255]; *s; s = &(*s)->next) {
-   struct bdev_map *p = *s;
-   if (p->dev == devt && p->range == range) {
-   *s = p->next;
-   if (!found)
-   found = p;
-   break;
-   }
-   }
+   for (i = 0; i < disk->minors; i++) {
+   if (xa_insert(&bdev_map, disk_devt(disk) + i, disk, GFP_KERNEL))
+   WARN_ON_ONCE(1);
}
mutex_unlock(&bdev_map_lock);
-   kfree(found);
 }
-EXPORT_SYMBOL(blk_unregister_region);
 
-static struct kobject *exact_match(dev_t devt, int *partno, void *data)
+static void blk_unregister_region(struct gendisk *disk)
 {
-   struct gendisk *p = data;
-
-   return &disk_to_dev(p)->kobj;
-}
-
-static int exact_lock(dev_t devt, void *data)
-{
-   struct gendisk *p = data;
+   int i;
 
-   if (!get_disk_and_module(p))
-   return -1;
-   return 0;
+   mutex_lock(&bdev_map_lock);
+   for (i = 0; i < disk->minors; i++)
+   xa_erase(&bdev_map, disk_devt(disk) + i);
+   mutex_lock(&bdev_map_lock);
 }
 
 static void register_disk(struct device *parent, struct gendisk *disk,
@@ -878,8 +811,7 @@ static void __device_add_disk(struct device *parent, struct 
gendisk *disk,
ret = bdi_register(bdi, "%u:%u", MAJOR(devt), MINOR(devt));
WARN_ON(ret);
bdi_set_owner(bdi, dev);
-   blk_register_region(disk_devt(disk), disk->minors, NULL,
-   exact_match, exact_lock, disk);
+   blk_register_region(disk);
}
register_disk(parent, disk, groups);
if (register_queue)
@@ -987,7 +919,7 @@ void del_gendisk(struct gendisk *disk)
 */
bdi_unregister(disk->queue->backing_dev_info);
blk_unregister_queue(disk);
-   blk_unregister_region(disk_devt(disk), disk->minors);
+   blk_unregister_region(disk);
} else {
blk_unregister_queue(disk);
}
@@ -1057,54 +989,22 @@ static v

Re: [PATCH v1 4/9] extcon: extcon-ptn5150: Switch to BIT() for cable detach macro

[Krzysztof Kozlowski]

On Tue, Aug 18, 2020 at 02:57:22PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Switch to BIT() macro for the cable detach.

Squash it.

Best regards,
Krzysztof

> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index fab862d9aad8..50fff148b772 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -45,10 +45,7 @@ enum ptn5150_reg {
>  #define PTN5150_REG_CC_VBUS_DETECTIONBIT(7)
>  
>  #define PTN5150_REG_INT_CABLE_ATTACH_MASKBIT(0)
> -
> -#define PTN5150_REG_INT_CABLE_DETACH_SHIFT   1
> -#define PTN5150_REG_INT_CABLE_DETACH_MASK\
> - (0x1 << PTN5150_REG_CC_CABLE_DETACH_SHIFT)
> +#define PTN5150_REG_INT_CABLE_DETACH_MASKBIT(1)
>  
>  struct ptn5150_info {
>   struct device *dev;
> -- 
> 2.11.0
> 

[PATCH 16/19] ataflop: use a separate gendisk for each media format

[Christoph Hellwig]

The Atari floppy driver usually autodetects the media when used with the
ormal /dev/fd? devices, which also are the only nodes created by udev.
But it also supports various aliases that force a given media format.
That is currently supported using the blk_register_region framework
which finds the floppy gendisk even for a 'mismatched' dev_t.  The
problem with this (besides the code complexity) is that it creates
multiple struct block_device instances for the whole device of a
single gendisk, which can lead to interesting issues in code not
aware of that fact.

To fix this just create a separate gendisk for each of the aliases
if they are accessed.

Signed-off-by: Christoph Hellwig 
---
 drivers/block/ataflop.c | 135 +---
 1 file changed, 86 insertions(+), 49 deletions(-)

diff --git a/drivers/block/ataflop.c b/drivers/block/ataflop.c
index a50e13af030526..b5acc85328c329 100644
--- a/drivers/block/ataflop.c
+++ b/drivers/block/ataflop.c
@@ -297,7 +297,7 @@ static struct atari_floppy_struct {
unsigned int wpstat;/* current state of WP signal (for
   disk change detection) */
int flags;  /* flags */
-   struct gendisk *disk;
+   struct gendisk *disk[NUM_DISK_MINORS];
int ref;
int type;
struct blk_mq_tag_set tag_set;
@@ -723,12 +723,16 @@ static void fd_error( void )
 
 static int do_format(int drive, int type, struct atari_format_descr *desc)
 {
-   struct request_queue *q = unit[drive].disk->queue;
+   struct request_queue *q;
unsigned char   *p;
int sect, nsect;
unsigned long   flags;
int ret;
 
+   if (type)
+   type--;
+
+   q = unit[drive].disk[type]->queue;
blk_mq_freeze_queue(q);
blk_mq_quiesce_queue(q);
 
@@ -738,7 +742,7 @@ static int do_format(int drive, int type, struct 
atari_format_descr *desc)
local_irq_restore(flags);
 
if (type) {
-   if (--type >= NUM_DISK_MINORS ||
+   if (type >= NUM_DISK_MINORS ||
minor2disktype[type].drive_types > DriveType) {
ret = -EINVAL;
goto out;
@@ -1154,7 +1158,7 @@ static void fd_rwsec_done1(int status)
if (SUDT[-1].blocks > ReqBlock) {
/* try another disk type */
SUDT--;
-   set_capacity(unit[SelectedDrive].disk,
+   set_capacity(unit[SelectedDrive].disk[0],
SUDT->blocks);
} else
Probing = 0;
@@ -1169,7 +1173,7 @@ static void fd_rwsec_done1(int status)
 /* record not found, but not probing. Maybe stretch wrong ? Restart probing */
if (SUD.autoprobe) {
SUDT = atari_disk_type + 
StartDiskType[DriveType];
-   set_capacity(unit[SelectedDrive].disk,
+   set_capacity(unit[SelectedDrive].disk[0],
SUDT->blocks);
Probing = 1;
}
@@ -1515,7 +1519,7 @@ static blk_status_t ataflop_queue_rq(struct blk_mq_hw_ctx 
*hctx,
if (!UDT) {
Probing = 1;
UDT = atari_disk_type + StartDiskType[DriveType];
-   set_capacity(floppy->disk, UDT->blocks);
+   set_capacity(bd->rq->rq_disk, UDT->blocks);
UD.autoprobe = 1;
}
} 
@@ -1533,7 +1537,7 @@ static blk_status_t ataflop_queue_rq(struct blk_mq_hw_ctx 
*hctx,
}
type = minor2disktype[type].index;
UDT = &atari_disk_type[type];
-   set_capacity(floppy->disk, UDT->blocks);
+   set_capacity(bd->rq->rq_disk, UDT->blocks);
UD.autoprobe = 0;
}
 
@@ -1658,7 +1662,7 @@ static int fd_locked_ioctl(struct block_device *bdev, 
fmode_t mode,
printk (KERN_INFO "floppy%d: setting %s 
%p!\n",
drive, dtp->name, dtp);
UDT = dtp;
-   set_capacity(floppy->disk, UDT->blocks);
+   set_capacity(disk, UDT->blocks);
 
if (cmd == FDDEFPRM) {
  /* save settings as permanent default type */
@@ -1702,7 +1706,7 @@ static int fd_locked_ioctl(struct block_device *bdev, 
fmode_t mode,
return -EINVAL;
 
UDT = dtp;
-   set_capacity(floppy->disk, UDT->blocks);
+   set_capacity(disk, UDT->blocks);
 
return 0;
case FDMSGON:
@@ -1725,7 +1729,

[PATCH 17/19] z2ram: reindent

[Christoph Hellwig]

reindent the driver using Lident as the code style was far away from
normal Linux code.

Signed-off-by: Christoph Hellwig 
---
 drivers/block/z2ram.c | 497 --
 1 file changed, 237 insertions(+), 260 deletions(-)

diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
index 0e734802ee7cc6..566c653399d8d3 100644
--- a/drivers/block/z2ram.c
+++ b/drivers/block/z2ram.c
@@ -42,7 +42,6 @@
 
 #include 
 
-
 #define Z2MINOR_COMBINED  (0)
 #define Z2MINOR_Z2ONLY(1)
 #define Z2MINOR_CHIPONLY  (2)
@@ -52,15 +51,15 @@
 #define Z2MINOR_MEMLIST4  (7)
 #define Z2MINOR_COUNT (8) /* Move this down when adding a new minor */
 
-#define Z2RAM_CHUNK1024   ( Z2RAM_CHUNKSIZE >> 10 )
+#define Z2RAM_CHUNK1024   (Z2RAM_CHUNKSIZE >> 10)
 
 static DEFINE_MUTEX(z2ram_mutex);
-static u_long *z2ram_map= NULL;
-static u_long z2ram_size= 0;
-static int z2_count = 0;
-static int chip_count   = 0;
-static int list_count   = 0;
-static int current_device   = -1;
+static u_long *z2ram_map = NULL;
+static u_long z2ram_size = 0;
+static int z2_count = 0;
+static int chip_count = 0;
+static int list_count = 0;
+static int current_device = -1;
 
 static DEFINE_SPINLOCK(z2ram_lock);
 
@@ -71,13 +70,12 @@ static blk_status_t z2_queue_rq(struct blk_mq_hw_ctx *hctx,
 {
struct request *req = bd->rq;
unsigned long start = blk_rq_pos(req) << 9;
-   unsigned long len  = blk_rq_cur_bytes(req);
+   unsigned long len = blk_rq_cur_bytes(req);
 
blk_mq_start_request(req);
 
if (start + len > z2ram_size) {
-   pr_err(DEVICE_NAME ": bad access: block=%llu, "
-  "count=%u\n",
+   pr_err(DEVICE_NAME ": bad access: block=%llu, count=%u\n",
   (unsigned long long)blk_rq_pos(req),
   blk_rq_cur_sectors(req));
return BLK_STS_IOERR;
@@ -92,7 +90,7 @@ static blk_status_t z2_queue_rq(struct blk_mq_hw_ctx *hctx,
 
if (len < size)
size = len;
-   addr += z2ram_map[ start >> Z2RAM_CHUNKSHIFT ];
+   addr += z2ram_map[start >> Z2RAM_CHUNKSHIFT];
if (rq_data_dir(req) == READ)
memcpy(buffer, (char *)addr, size);
else
@@ -106,228 +104,213 @@ static blk_status_t z2_queue_rq(struct blk_mq_hw_ctx 
*hctx,
return BLK_STS_OK;
 }
 
-static void
-get_z2ram( void )
+static void get_z2ram(void)
 {
-int i;
-
-for ( i = 0; i < Z2RAM_SIZE / Z2RAM_CHUNKSIZE; i++ )
-{
-   if ( test_bit( i, zorro_unused_z2ram ) )
-   {
-   z2_count++;
-   z2ram_map[z2ram_size++] = (unsigned long)ZTWO_VADDR(Z2RAM_START) +
- (i << Z2RAM_CHUNKSHIFT);
-   clear_bit( i, zorro_unused_z2ram );
+   int i;
+
+   for (i = 0; i < Z2RAM_SIZE / Z2RAM_CHUNKSIZE; i++) {
+   if (test_bit(i, zorro_unused_z2ram)) {
+   z2_count++;
+   z2ram_map[z2ram_size++] =
+   (unsigned long)ZTWO_VADDR(Z2RAM_START) +
+   (i << Z2RAM_CHUNKSHIFT);
+   clear_bit(i, zorro_unused_z2ram);
+   }
}
-}
 
-return;
+   return;
 }
 
-static void
-get_chipram( void )
+static void get_chipram(void)
 {
 
-while ( amiga_chip_avail() > ( Z2RAM_CHUNKSIZE * 4 ) )
-{
-   chip_count++;
-   z2ram_map[ z2ram_size ] =
-   (u_long)amiga_chip_alloc( Z2RAM_CHUNKSIZE, "z2ram" );
+   while (amiga_chip_avail() > (Z2RAM_CHUNKSIZE * 4)) {
+   chip_count++;
+   z2ram_map[z2ram_size] =
+   (u_long) amiga_chip_alloc(Z2RAM_CHUNKSIZE, "z2ram");
 
-   if ( z2ram_map[ z2ram_size ] == 0 )
-   {
-   break;
+   if (z2ram_map[z2ram_size] == 0) {
+   break;
+   }
+
+   z2ram_size++;
}
 
-   z2ram_size++;
-}
-   
-return;
+   return;
 }
 
 static int z2_open(struct block_device *bdev, fmode_t mode)
 {
-int device;
-int max_z2_map = ( Z2RAM_SIZE / Z2RAM_CHUNKSIZE ) *
-   sizeof( z2ram_map[0] );
-int max_chip_map = ( amiga_chip_size / Z2RAM_CHUNKSIZE ) *
-   sizeof( z2ram_map[0] );
-int rc = -ENOMEM;
-
-device = MINOR(bdev->bd_dev);
-
-mutex_lock(&z2ram_mutex);
-if ( current_device != -1 && current_device != device )
-{
-   rc = -EBUSY;
-   goto err_out;
-}
-
-if ( current_device == -1 )
-{
-   z2_count   = 0;
-   chip_count = 0;
-   list_count = 0;
-   z2ram_size = 0;
-
-   /* Use a specific list entry. */
-   if (device >= Z2MINOR_MEMLIST1 && device <= Z2MINOR_MEMLIST4) {
-   int index = device - Z2MINOR_MEMLIST1 + 1;
-   unsigned long size, paddr, vaddr;
-
-   if (index >= m68k_realnum_memory) {
-   

Re: [PATCH v1 5/9] extcon: extcon-ptn5150: Switch to GENMASK() for port attachment macro

[Krzysztof Kozlowski]

On Tue, Aug 18, 2020 at 02:57:23PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan 
> 
> Switch to GENMASK() macro for the port attachment.

Squash it.

Best regards,
Krzysztof

> 
> Signed-off-by: Ramuthevar Vadivel Murugan 
> 
> ---
>  drivers/extcon/extcon-ptn5150.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
> index 50fff148b772..31b7cbf1551d 100644
> --- a/drivers/extcon/extcon-ptn5150.c
> +++ b/drivers/extcon/extcon-ptn5150.c
> @@ -38,9 +38,7 @@ enum ptn5150_reg {
>  #define PTN5150_REG_DEVICE_ID_VERSIONGENMASK(7, 3)
>  #define PTN5150_REG_DEVICE_ID_VENDOR GENMASK(2, 0)
>  
> -#define PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT 2
> -#define PTN5150_REG_CC_PORT_ATTACHMENT_MASK  \
> - (0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
> +#define PTN5150_REG_CC_PORT_ATTACHMENT   GENMASK(4, 2)
>  
>  #define PTN5150_REG_CC_VBUS_DETECTIONBIT(7)
>  
> @@ -108,9 +106,8 @@ static void ptn5150_irq_work(struct work_struct *work)
>   unsigned int port_status;
>   unsigned int vbus;
>  
> - port_status = ((reg_data &
> - PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
> - PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
> + port_status = FIELD_GET(PTN5150_REG_CC_PORT_ATTACHMENT,
> + reg_data);
>  
>   switch (port_status) {
>   case PTN5150_DFP_ATTACHED:
> -- 
> 2.11.0
> 

Re: [PATCH] iio: dpot-dac: fix code comment in dpot_dac_read_raw()

[Peter Rosin]

Hi!

On 2020-08-26 02:08, Gustavo A. R. Silva wrote:
> After the replacement of the /* fall through */ comment with the
> fallthrough pseudo-keyword macro, the natural reading of a code
> comment was broken.
> 
> Fix the natural reading of such a comment and make it intelligible.
> 
> Reported-by: Peter Rosin 
> Signed-off-by: Gustavo A. R. Silva 

Excellent, thanks for the quick turnaround!

And just to be explicit, this fix is for 5.9.

Acked-by: Peter Rosin 

Cheers,
Peter

Re: [RFC PATCH 2/3] dmaengine: add peripheral configuration

[Peter Ujfalusi]

Hi Vinod,

On 25/08/2020 14.02, Vinod Koul wrote:
>> The only thing which might be an issue is that with the DMA_PREP_CMD the
>> config_data is dma_addr_t (via dmaengine_prep_slave_single).
> 
> Yes I came to same conclusion
> 
>>> I did have a prototype with metadata but didnt work very well, the
>>> problem is it assumes metadata for tx/rx but here i send the data
>>> everytime from client data.
>>
>> Yes, the intended use case for metadata (per descriptor!) is for
>> channels where each transfer might have different metadata needed for
>> the given transfer (tx/rx).
>>
>> In your case you have semi static peripheral configuration data, which
>> is not really changing between transfers.
>>
>> A compromise would be to add:
>> void *peripheral_config;
>> to the dma_slave_config, move the set_config inside of the device
>> specific struct you are passing from a client to the core?
> 
> That sounds more saner to me and uses existing interfaces cleanly. I
> think I like this option ;-)

The other option would be to use the descriptor metadata support and
that might be even cleaner.

In gpi_create_tre() via gpi_prep_slave_sg() you would set up the
desc->tre[1] and desc->tre[2] for TX
desc->tre[2] for RX
in the desc, you add a new variable, let's say first_tre and
set it to 1 for TX, 2 for RX.

If you need to send a config, you attach it via either way metadata
support allows you (get the pointer to desc->tre[0] or give a config
struct to the DMA driver.

In the metadata handler, you check if the transfer is TX, if it is, then
you update desc->tre[0] (or give the pointer to the client) and update
the first_tre to 0.

In issue_pending, or a small helper which can be used to start the
transfer you would do the queuing instead of prepare time:
for (i = gpi_desc->first_tre; i < MAX_TRE; i++)
gpi_queue_xfer(gpii, gpii_chan,  &gpi_desc->tre[i], &wp);

With this change it should work neatly without any change to
dma_slave_config.

> 
 I'm concerned about the size increase of dma_slave_config (it grows by
> 30 bytes) and for DMAs with hundreds of channels (UDMA) it will add up
 to a sizeable amount.
>>>
>>> I agree that is indeed a valid concern, that is the reason I tagged this
>>> as a RFC patch ;-)
>>>
>>> I see the prep_cmd is a better approach for this, anyone else has better
>>> suggestions?
>>>
>>> Thanks for looking in.
>>>
>>
>> - Péter
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [RFC v4 16/20] drm/i915/dp: Extract drm_dp_get_sink_count()

[Jani Nikula]

On Tue, 25 Aug 2020, Lyude Paul  wrote:
> And of course, we'll also need to read the sink count from other drivers
> as well if we're checking whether or not it's supported. So, let's
> extract the code for this into another helper.
>
> v2:
> * Fix drm_dp_dpcd_readb() ret check
> * Add back comment and move back sink_count assignment in intel_dp_get_dpcd()
>
> Signed-off-by: Lyude Paul 
> Reviewed-by: Sean Paul 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 22 ++
>  drivers/gpu/drm/i915/display/intel_dp.c | 11 +--
>  include/drm/drm_dp_helper.h |  1 +
>  3 files changed, 28 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 863e0babc1903..67ad05eb05b7e 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -736,6 +736,28 @@ bool drm_dp_has_sink_count(struct drm_connector 
> *connector,
>  }
>  EXPORT_SYMBOL(drm_dp_has_sink_count);
>  
> +/**
> + * drm_dp_get_sink_count() - Retrieve the sink count for a given sink

>From the department of bikeshedding...

Should we have a naming scheme where it's obvious whether a function
will do DPCD access, or just shuffle existing data?

For example, drm_dp_read_foo() for anything with DPCD access
vs. drm_dp_get_foo() or even simpler for anything that only processes
pre-read data?

> + * @aux: The DP AUX channel to use
> + *
> + * Returns: The current sink count reported by @aux, or a negative error code
> + * otherwise.
> + */
> +int drm_dp_get_sink_count(struct drm_dp_aux *aux)
> +{
> + u8 count;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_SINK_COUNT, &count);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;

Makes me wonder if that shouldn't be at drm_dp_dpcd_read() level, for
reads returning 0..len-1 bytes. Not necessarily part of this series, but
seems silly to set a precedent to start handling that return value all
over the place.

BR,
Jani.

> +
> + return DP_GET_SINK_COUNT(count);
> +}
> +EXPORT_SYMBOL(drm_dp_get_sink_count);
> +
>  /*
>   * I2C-over-AUX implementation
>   */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 35a4779a442e2..4337321a3be4f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4648,6 +4648,8 @@ intel_dp_has_sink_count(struct intel_dp *intel_dp)
>  static bool
>  intel_dp_get_dpcd(struct intel_dp *intel_dp)
>  {
> + int ret;
> +
>   if (!intel_dp_read_dpcd(intel_dp))
>   return false;
>  
> @@ -4664,11 +4666,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   }
>  
>   if (intel_dp_has_sink_count(intel_dp)) {
> - u8 count;
> - ssize_t r;
> -
> - r = drm_dp_dpcd_readb(&intel_dp->aux, DP_SINK_COUNT, &count);
> - if (r < 1)
> + ret = drm_dp_get_sink_count(&intel_dp->aux);
> + if (ret < 0)
>   return false;
>  
>   /*
> @@ -4676,7 +4675,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>* a member variable in intel_dp will track any changes
>* between short pulse interrupts.
>*/
> - intel_dp->sink_count = DP_GET_SINK_COUNT(count);
> + intel_dp->sink_count = ret;
>  
>   /*
>* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index a1413a531eaf4..0c141fc81aaa8 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -1635,6 +1635,7 @@ struct drm_dp_desc;
>  bool drm_dp_has_sink_count(struct drm_connector *connector,
>  const u8 dpcd[DP_RECEIVER_CAP_SIZE],
>  const struct drm_dp_desc *desc);
> +int drm_dp_get_sink_count(struct drm_dp_aux *aux);
>  
>  void drm_dp_remote_aux_init(struct drm_dp_aux *aux);
>  void drm_dp_aux_init(struct drm_dp_aux *aux);

-- 
Jani Nikula, Intel Open Source Graphics Center

RE: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)

[eddy...@trendmicro.com]

> -Original Message-
> From: pet...@infradead.org 
> Sent: Tuesday, August 25, 2020 8:09 PM
> To: Masami Hiramatsu 
> Cc: Eddy Wu (RD-TW) ; linux-kernel@vger.kernel.org; 
> x...@kernel.org; David S. Miller
> 
> Subject: Re: x86/kprobes: kretprobe fails to triggered if kprobe at function 
> entry is not optimized (trigger by int3 breakpoint)
>
> Surely we can do a lockless list for this. We have llist_add() and
> llist_del_first() to make a lockless LIFO/stack.
>

llist operations require atomic cmpxchg, for some arch doesn't have 
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, in_nmi() check might still needed.
(HAVE_KRETPROBES && !CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG): arc, arm, csky, mips

TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential and 
may be subject to copyright or other intellectual property protection. If you 
are not the intended recipient, you are not authorized to use or disclose this 
information, and we request that you notify us by reply mail or telephone and 
delete the original message from your mail system.

For details about what personal information we collect and why, please see our 
Privacy Notice on our website at: Read privacy 
policy

Re: [PATCH 1/3] net: ax88796c: ASIX AX88796C SPI Ethernet Adapter Driver

[Geert Uytterhoeven]

On Tue, Aug 25, 2020 at 8:02 PM Andrew Lunn  wrote:
> On Tue, Aug 25, 2020 at 07:03:09PM +0200, Łukasz Stelmach wrote:
> > + if (netif_msg_pktdata(ax_local)) {
> > + int loop;
> > + netdev_info(ndev, "TX packet len %d, total len %d, seq %d\n",
> > + pkt_len, tx_skb->len, seq_num);
> > +
> > + netdev_info(ndev, "  Dump SPI Header:\n");
> > + for (loop = 0; loop < 4; loop++)
> > + netdev_info(ndev, "%02x ", *(tx_skb->data + loop));
> > +
> > + netdev_info(ndev, "\n");
>
> This no longer works as far as i remember. Lines are terminate by
> default even if they don't have a \n.
>
> Please you should not be using netdev_info(). netdev_dbg() please.

We have a nice helper for this: print_hex_dump_debug().

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer

[Arnd Bergmann]

On Wed, Aug 26, 2020 at 12:04 AM Michael Kelley  wrote:
> From: Arnd Bergmann  Sent: Monday, August 24, 2020 11:54 AM

> >
> > I'm not sure what the correct solution should be, but what I'd try to
> > do here is to move every function that just considers the platform
> > rather than the architecture somewhere into drivers/hv where it
> > can be linked into the same modules as the existing files when
> > building for arm64, while trying to keep architecture specific code
> > in the header file where it can be included from those modules.
>
> OK.  The concept of separating platform from architecture makes
> sense to me.  The original separation of the Hyper-V code into
> architecture independent portions and x86-specific portions could
> use some tweaking now that we're dealing with n=2 architectures.  With
> that tweaking, I can reduce the amount of Hyper-V code under arch/x86
> and under arch/arm64.
>
> On the flip side, the Hyper-V implementation on x86 and ARM64 has
> differences that are semi-related to the architecture.  For example, on
> x86 Hyper-V uses synthetic MSRs for a lot of guest-hypervisor setup, while
> hypercalls are required on ARM64.  So I'm assuming those differences
> will end up in code under arch/x86 and arch/arm64.

Yes, that absolutely makes sense.

> Arguably, I could introduce a level of indirection (such as
> CONFIG_HYPERV_USE_MSRS vs.
> CONFIG_HYPERV_USE_HYPERCALLS) to distinguish the two behaviors.
> The selection would be tied to the architecture, and then code in
> drivers/hv can #ifdef the two cases.  But I wonder if getting code out of
> arch/x86 and arch/arm64 is worth that additional messiness.

No, I think that would take it a little too far, and conflicts with the
generic rule that code under drivers/* should be written to be portable
even if can only run on a particular target platform.

> Looking at the Xen code in drivers/xen, it looks like a lot of the Xen 
> functionality
> is implemented in hypercalls that can be consistent across architectures,
> though I was a bit surprised to see a dozen or so instances of #ifdef 
> CONFIG_X86.
> Xen also #ifdefs on PV vs. PVHVM, which may handle some architecture
> differences implicitly.  But I'm assuming that doing #ifdef 
> in the Hyper-V code in order to reduce code under arch/x86 or arch/arm64
> is not the right way to go.

In general that is true, adding a lot of #ifdefs makes code less readable and
harder to test. OTOH there are cases where a single #ifdef can be useful when
it avoids adding a larger amount of complexity elsewhere. Many subsystems
try to restrict the #ifdef checks to header files while keeping the
drivers/* code
free of them.

   Arnd

Re: [PATCH] net: cdc_ncm: Fix build error

[Bjørn Mork]

YueHaibing  writes:

> If USB_NET_CDC_NCM is y and USB_NET_CDCETHER is m, build fails:
>
> drivers/net/usb/cdc_ncm.o:(.rodata+0x1d8): undefined reference to 
> `usbnet_cdc_update_filter'
>
> Select USB_NET_CDCETHER for USB_NET_CDC_NCM to fix this.

Ouch.  For some reason I assumed that was always selected with usbnet.
Thanks for fixing.



Bjørn

Re: [PATCH 3/3] usb: cdns3: Enable workaround for USB2.0 PHY Rx compliance test PHY lockup

[Peter Chen]

On 20-08-26 04:04:01, Pawel Laszczak wrote:
> >On 20-08-25 15:00:59, Roger Quadros wrote:
> >> From: Pawel Laszczak 
> >>
> >> USB2.0 PHY hangs in Rx Compliance test when the incoming packet
> >> amplitude is varied below and above the Squelch Level of
> >> Receiver during the active packet multiple times.
> >>
> >> Version 1 of the controller allows PHY to be reset when RX fail condition
> >> is detected to work around the above issue. This feature is
> >> disabled by default and needs to be enabled using a bit from
> >> the newly added PHYRST_CFG register. This patch enables the workaround.
> >>
> >> As there is no way to distinguish between the controller version
> >> before the device controller is started we need to rely on a
> >> DT property to decide when to apply the workaround.
> >
> >Pawel, it could know the controller version at cdns3_gadget_start,
> >but the controller starts when it tries to bind gadget driver, at that
> >time, it has already known the controller version.
> >
> >For me, the device controller starts is using USB_CONF.DEVEN (Device
> >Enable) through usb_gadget_connect, I am not sure if it is the same
> >with yours.
> >
> 
> Yes in device mode driver knows controller version but this workaround 
> Must be enabled also in host mode. In host mode the controller 
> doesn't have access to device registers. The controller version is 
> placed in device register.
> 

You may suggest your design team adding CHIP_VER register at global
register region, it will easy the software engineer life.

>From what I read, this register is only enabling USB2 PHY reset software
control, it needs for all chips with rev 0x0002450D, and the place you
current change is only for 0x0002450D, right?

Peter

> Pawel
> 
> >Peter
> >
> >
> >>
> >> Signed-off-by: Pawel Laszczak 
> >> Signed-off-by: Roger Quadros 
> >> ---
> >>  drivers/usb/cdns3/core.c |  2 ++
> >>  drivers/usb/cdns3/core.h |  1 +
> >>  drivers/usb/cdns3/drd.c  | 12 
> >>  drivers/usb/cdns3/drd.h  |  5 -
> >>  4 files changed, 19 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> >> index 5c1586ec7824..34b36487682b 100644
> >> --- a/drivers/usb/cdns3/core.c
> >> +++ b/drivers/usb/cdns3/core.c
> >> @@ -443,6 +443,8 @@ static int cdns3_probe(struct platform_device *pdev)
> >>return -ENXIO;
> >>}
> >>
> >> +  cdns->phyrst_a_enable = device_property_read_bool(dev, 
> >> "cdns,phyrst-a-enable");
> >> +
> >>cdns->otg_res = *res;
> >>
> >>mutex_init(&cdns->mutex);
> >> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
> >> index 1ad1f1fe61e9..24cf0f1b5726 100644
> >> --- a/drivers/usb/cdns3/core.h
> >> +++ b/drivers/usb/cdns3/core.h
> >> @@ -76,6 +76,7 @@ struct cdns3 {
> >>  #define CDNS3_CONTROLLER_V0   0
> >>  #define CDNS3_CONTROLLER_V1   1
> >>u32 version;
> >> +  boolphyrst_a_enable;
> >>
> >>int otg_irq;
> >>int dev_irq;
> >> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
> >> index 6234bcd6158a..b74803e9703d 100644
> >> --- a/drivers/usb/cdns3/drd.c
> >> +++ b/drivers/usb/cdns3/drd.c
> >> @@ -42,6 +42,18 @@ int cdns3_set_mode(struct cdns3 *cdns, enum usb_dr_mode 
> >> mode)
> >>reg = readl(&cdns->otg_v1_regs->override);
> >>reg |= OVERRIDE_IDPULLUP;
> >>writel(reg, &cdns->otg_v1_regs->override);
> >> +
> >> +  /*
> >> +   * Enable work around feature built into the
> >> +   * controller to address issue with RX Sensitivity
> >> +   * est (EL_17) for USB2 PHY. The issue only occures
> >> +   * for 0x0002450D controller version.
> >> +   */
> >> +  if (cdns->phyrst_a_enable) {
> >> +  reg = readl(&cdns->otg_v1_regs->phyrst_cfg);
> >> +  reg |= PHYRST_CFG_PHYRST_A_ENABLE;
> >> +  writel(reg, &cdns->otg_v1_regs->phyrst_cfg);
> >> +  }
> >>} else {
> >>reg = readl(&cdns->otg_v0_regs->ctrl1);
> >>reg |= OVERRIDE_IDPULLUP_V0;
> >> diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
> >> index 7e7cf7fa2dd3..f1ccae285a16 100644
> >> --- a/drivers/usb/cdns3/drd.h
> >> +++ b/drivers/usb/cdns3/drd.h
> >> @@ -31,7 +31,7 @@ struct cdns3_otg_regs {
> >>__le32 simulate;
> >>__le32 override;
> >>__le32 susp_ctrl;
> >> -  __le32 reserved4;
> >> +  __le32 phyrst_cfg;
> >>__le32 anasts;
> >>__le32 adp_ramp_time;
> >>__le32 ctrl1;
> >> @@ -153,6 +153,9 @@ struct cdns3_otg_common_regs {
> >>  /* Only for CDNS3_CONTROLLER_V0 version */
> >>  #define OVERRIDE_IDPULLUP_V0  BIT(24)
> >>
> >> +/* PHYRST_CFG - bitmasks */
> >> +#define PHYRST_CFG_PHYRST_A_ENABLE  

[PATCH 3/4] media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.rst files

[Mauro Carvalho Chehab]

There are some files that are dual licensed GPL and GFDL.

As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

Let's remove the dual license text, replacing them by:

SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later

Signed-off-by: Mauro Carvalho Chehab 
---
 .../mediactl/media-ioc-request-alloc.rst  | 26 +--
 .../mediactl/media-request-ioc-queue.rst  | 26 +--
 .../mediactl/media-request-ioc-reinit.rst | 26 +--
 .../media/mediactl/request-api.rst| 26 +--
 .../media/mediactl/request-func-close.rst | 26 +--
 .../media/mediactl/request-func-ioctl.rst | 26 +--
 .../media/mediactl/request-func-poll.rst  | 26 +--
 .../userspace-api/media/v4l/dev-encoder.rst   | 26 +--
 .../media/v4l/pixfmt-meta-intel-ipu3.rst  | 25 +-
 .../media/v4l/pixfmt-meta-vivid.rst   | 26 +--
 10 files changed, 10 insertions(+), 249 deletions(-)

diff --git 
a/Documentation/userspace-api/media/mediactl/media-ioc-request-alloc.rst 
b/Documentation/userspace-api/media/mediactl/media-ioc-request-alloc.rst
index 82f86466c7f2..ea05ff0c5382 100644
--- a/Documentation/userspace-api/media/mediactl/media-ioc-request-alloc.rst
+++ b/Documentation/userspace-api/media/mediactl/media-ioc-request-alloc.rst
@@ -1,28 +1,4 @@
-.. This file is dual-licensed: you can use it either under the terms
-.. of the GPL 2.0 or the GFDL 1.1+ license, at your option. Note that this
-.. dual licensing only applies to this file, and not this project as a
-.. whole.
-..
-.. a) This file is free software; you can redistribute it and/or
-..modify it under the terms of the GNU General Public License as
-..published by the Free Software Foundation version 2 of
-..the License.
-..
-..This file is distributed in the hope that it will be useful,
-..but WITHOUT ANY WARRANTY; without even the implied warranty of
-..MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-..GNU General Public License for more details.
-..
-.. Or, alternatively,
-..
-.. b) Permission is granted to copy, distribute and/or modify this
-..document under the terms of the GNU Free Documentation License,
-..Version 1.1 or any later version published by the Free Software
-..Foundation, with no Invariant Sections, no Front-Cover Texts
-..and no Back-Cover Texts. A copy of the license is included at
-..Documentation/userspace-api/media/fdl-appendix.rst.
-..
-.. TODO: replace it to GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
 
 .. _media_ioc_request_alloc:
 
diff --git 
a/Documentation/userspace-api/media/mediactl/media-request-ioc-queue.rst 
b/Documentation/userspace-api/media/mediactl/media-request-ioc-queue.rst
index ad55b6b32616..ca1b33196242 100644
--- a/Documentation/userspace-api/media/mediactl/media-request-ioc-queue.rst
+++ b/Documentation/userspace-api/media/mediactl/media-request-ioc-queue.rst
@@ -1,28 +1,4 @@
-.. This file is dual-licensed: you can use it either under the terms
-.. of the GPL 2.0 or the GFDL 1.1+ license, at your option. Note that this
-.. dual licensing only applies to this file, and not this project as a
-.. whole.
-..
-.. a) This file is free software; you can redistribute it and/or
-..modify it under the terms of the GNU General Public License as
-..published by the Free Software Foundation version 2 of
-..the License.
-..
-..This file is distributed in the hope that it will be useful,
-..but WITHOUT ANY WARRANTY; without even the implied warranty of
-..MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-..GNU General Public License for more details.
-..
-.. Or, alternatively,
-..
-.. b) Permission is granted to copy, distribute and/or modify this
-..document under the terms of the GNU Free Documentation License,
-..Version 1.1 or any later version published by the Free Software
-..Foundation, with no Invariant Sections, no Front-Cover Texts
-..and no Back-Cover Texts. A copy of the license is included at
-..Documentation/userspace-api/media/fdl-appendix.rst.
-..
-.. TODO: replace it to GPL-2.0 OR GFDL-1.1-or-later WITH no-invariant-sections
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
 
 .. _media_request_ioc_queue:
 
diff --git 
a/Documentation/userspace-api/media/mediactl/media-request-ioc-reinit.rst 
b/Documentation/userspace-api/media/mediactl/media-request-ioc-reinit.rst
index 4c43fa05c8f6..cfd503bdef70 100644
--- a/Documentation/userspace-api/media/mediactl/media-request-ioc-reinit.rst
+++ b/Documentation/userspace-api/media/mediactl/media-request-ioc-reinit.rst
@@ -1,28 +1,4 @@
-.. This file is dual-licensed: you can use it eithe

[PATCH 2/4] media: docs: use the new SPDX header for GFDL-1.1 on *.svg files

[Mauro Carvalho Chehab]

SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

So, remove the license text, replacing them by this new SPDX license.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../userspace-api/media/typical_media_device.svg  | 11 +--
 Documentation/userspace-api/media/v4l/crop.svg| 11 +--
 Documentation/userspace-api/media/v4l/fieldseq_bt.svg | 11 +--
 Documentation/userspace-api/media/v4l/fieldseq_tb.svg | 11 +--
 .../media/v4l/subdev-image-processing-crop.svg| 11 +--
 .../media/v4l/subdev-image-processing-full.svg| 11 +--
 .../subdev-image-processing-scaling-multi-source.svg  | 11 +--
 Documentation/userspace-api/media/v4l/vbi_525.svg | 11 +--
 Documentation/userspace-api/media/v4l/vbi_625.svg | 11 +--
 Documentation/userspace-api/media/v4l/vbi_hsync.svg   | 11 +--
 10 files changed, 10 insertions(+), 100 deletions(-)

diff --git a/Documentation/userspace-api/media/typical_media_device.svg 
b/Documentation/userspace-api/media/typical_media_device.svg
index 3420341ff7b6..fca7af8e438b 100644
--- a/Documentation/userspace-api/media/typical_media_device.svg
+++ b/Documentation/userspace-api/media/typical_media_device.svg
@@ -1,14 +1,5 @@
 
-
+
 http://www.w3.org/2000/svg"; 
xmlns:cc="http://creativecommons.org/ns#"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>Audio 
decoder
diff --git a/Documentation/userspace-api/media/v4l/crop.svg 
b/Documentation/userspace-api/media/v4l/crop.svg
index 4cd47f98e7c8..5483227757e7 100644
--- a/Documentation/userspace-api/media/v4l/crop.svg
+++ b/Documentation/userspace-api/media/v4l/crop.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/fieldseq_bt.svg 
b/Documentation/userspace-api/media/v4l/fieldseq_bt.svg
index b663f6fcb70b..91ac2813b454 100644
--- a/Documentation/userspace-api/media/v4l/fieldseq_bt.svg
+++ b/Documentation/userspace-api/media/v4l/fieldseq_bt.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/fieldseq_tb.svg 
b/Documentation/userspace-api/media/v4l/fieldseq_tb.svg
index f8b440a1cb60..7b4f8fb33757 100644
--- a/Documentation/userspace-api/media/v4l/fieldseq_tb.svg
+++ b/Documentation/userspace-api/media/v4l/fieldseq_tb.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git 
a/Documentation/userspace-api/media/v4l/subdev-image-processing-crop.svg 
b/Documentation/userspace-api/media/v4l/subdev-image-processing-crop.svg
index 109bbcebd3b4..d92311281e01 100644
--- a/Documentation/userspace-api/media/v4l/subdev-image-processing-crop.svg
+++ b/Documentation/userspace-api/media/v4l/subdev-image-processing-crop.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git 
a/Documentation/userspace-api/media/v4l/subdev-image-processing-full.svg 
b/Documentation/userspace-api/media/v4l/subdev-image-processing-full.svg
index cfdb7532d5b6..864a594ff8d0 100644
--- a/Documentation/userspace-api/media/v4l/subdev-image-processing-full.svg
+++ b/Documentation/userspace-api/media/v4l/subdev-image-processing-full.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git 
a/Documentation/userspace-api/media/v4l/subdev-image-processing-scaling-multi-source.svg
 
b/Documentation/userspace-api/media/v4l/subdev-image-processing-scaling-multi-source.svg
index f7f1379d30a6..b75755d31f15 100644
--- 
a/Documentation/userspace-api/media/v4l/subdev-image-processing-scaling-multi-source.svg
+++ 
b/Documentation/userspace-api/media/v4l/subdev-image-processing-scaling-multi-source.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/vbi_525.svg 
b/Documentation/userspace-api/media/v4l/vbi_525.svg
index b7d09057617e..b01086d466a6 100644
--- a/Documentation/userspace-api/media/v4l/vbi_525.svg
+++ b/Documentation/userspace-api/media/v4l/vbi_525.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/vbi_625.svg 
b/Documentation/userspace-api/media/v4l/vbi_625.svg
index e1f5e8552c37..41c1ce920d14 100644
--- a/Documentation/userspace-api/media/v4l/vbi_625.svg
+++ b/Documentation/userspace-api/media/v4l/vbi_625.svg
@@ -1,14 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/vbi_hsync.sv

Re: [PATCH v7 07/10] arm64: hyperv: Initialize hypervisor on boot

[Arnd Bergmann]

On Tue, Aug 25, 2020 at 11:20 PM Michael Kelley  wrote:
> From: Arnd Bergmann  Sent: Monday, August 24, 2020 11:34 AM
> > On Mon, Aug 24, 2020 at 6:48 PM Michael Kelley  
> > wrote:
> >
> > I think this has come up before, and I still don't consider it an acceptable
> > hack to hook platform initialization code into the timer code.
> >
> > Please split out the timer into a standalone driver in drivers/clocksource
> > that can get reviewed by the clocksource maintainers.
>
> I see two related topics here.

Agreed

>  First, the Hyper-V clocksource driver is
> drivers/clocksource/hyperv_timer.c.  The code is architecture independent
> and is used today on the x86 side and for ARM64 in this patch series.  A few
> architecture specific calls are satisfied by code under arch/x86, and in this
> patch series, under arch/arm64.  Is there some aspect of this driver that
> needs reconsideration?  I just want to make sure to understand what you
> are getting at.

For the clocksource driver, I would like to see the arm64 specific bits
(the code you add in arch/arm64 that are only relevant to this driver)
moved out of arch/arm64 and into drivers/clocksource, in whatever
form the clocksource maintainers prefer. I would suggest having a
separate file that can get linked along with the architecture-independent
part of that driver.

> Second is the question of where/how to do Hyper-V specific initialization.
> I agree that hanging it off the timer initialization isn't a great approach.
> Should I add a Hyper-V specific initialization call at the appropriate point
> in the ARM64 init sequence?  The x86 side has some structure for handling
> multiple hypervisors, and the Hyper-V initialization code naturally plugs into
> that structure.  I'm certainly open to suggestions on the best way to handle
> it for ARM64.

Yes, that is where I was getting at. Maybe the x86 abstraction for handling
multiple hypervisors can be lifted out of arch/x86/ into common code?

   Arnd

[PATCH 4/4] media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.svg files

[Mauro Carvalho Chehab]

There are some files that are dual licensed GPL and GFDL.

As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:

https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html

Let's remove the dual license text, replacing them by:

SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later

Signed-off-by: Mauro Carvalho Chehab 
---
 .../userspace-api/media/dvb/dvbstb.svg| 28 +--
 .../userspace-api/media/v4l/bayer.svg | 28 +--
 .../userspace-api/media/v4l/constraints.svg   | 28 +--
 .../userspace-api/media/v4l/nv12mt.svg| 28 +--
 .../media/v4l/nv12mt_example.svg  | 28 +--
 .../userspace-api/media/v4l/selection.svg | 28 +--
 6 files changed, 6 insertions(+), 162 deletions(-)

diff --git a/Documentation/userspace-api/media/dvb/dvbstb.svg 
b/Documentation/userspace-api/media/dvb/dvbstb.svg
index b333d0ff944f..87e68baa056b 100644
--- a/Documentation/userspace-api/media/dvb/dvbstb.svg
+++ b/Documentation/userspace-api/media/dvb/dvbstb.svg
@@ -1,31 +1,5 @@
 
-
+
 http://www.w3.org/2000/svg"; xmlns:cc="http://creativecommons.org/ns#"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>Antena
diff --git a/Documentation/userspace-api/media/v4l/bayer.svg 
b/Documentation/userspace-api/media/v4l/bayer.svg
index 82e805c68c1f..c500a28f0817 100644
--- a/Documentation/userspace-api/media/v4l/bayer.svg
+++ b/Documentation/userspace-api/media/v4l/bayer.svg
@@ -1,31 +1,5 @@
 
-
+
 http://www.w3.org/2000/svg"; xmlns:cc="http://creativecommons.org/ns#"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>B
 G
diff --git a/Documentation/userspace-api/media/v4l/constraints.svg 
b/Documentation/userspace-api/media/v4l/constraints.svg
index 1dfe51a9839d..ac5f82bc6d1a 100644
--- a/Documentation/userspace-api/media/v4l/constraints.svg
+++ b/Documentation/userspace-api/media/v4l/constraints.svg
@@ -1,31 +1,5 @@
 
-
+
 http://www.w3.org/2000/svg"; xmlns:cc="http://creativecommons.org/ns#"; 
xmlns:dc="http://purl.org/dc/elements/1.1/"; 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";>image/svg+xmlhttp://purl.org/dc/dcmitype/StillImage"/>
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/nv12mt_example.svg 
b/Documentation/userspace-api/media/v4l/nv12mt_example.svg
index e5075af9f45a..d1e2023f4973 100644
--- a/Documentation/userspace-api/media/v4l/nv12mt_example.svg
+++ b/Documentation/userspace-api/media/v4l/nv12mt_example.svg
@@ -1,31 +1,5 @@
 
-
+
 http://purl.org/dc/elements/1.1/";
xmlns:cc="http://creativecommons.org/ns#";
diff --git a/Documentation/userspace-api/media/v4l/selection.svg 
b/Documentation/userspace-api/media/v4l/selection.svg
index c0e00ab2ae6b..6305b53b8e54 100644
--- a/Documentation/userspace-api/media/v4l/selection.svg
+++ b/Documentation/userspace-api/media/v4l/selection.svg
@@ -1,31 +1,5 @@
 
-
+
 http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink";>
  
   
-- 
2.26.2

[PATCH] ARM: config: aspeed: Fix selection of media drivers

[Joel Stanley]

In the 5.7 merge window the media kconfig was restructued. For most
platforms these changes set CONFIG_MEDIA_SUPPORT_FILTER=y which keeps
unwanted drivers disabled.

The exception is if a config sets EMBEDDED or EXPERT (see b0cd4fb27665).
In that case the filter is set to =n, causing a bunch of DVB tuner drivers
(MEDIA_TUNER_*) to be accidentally enabled. This was noticed as it blew
out the build time for the Aspeed defconfigs.

Enabling the filter means the Aspeed config also needs to set
CONFIG_MEDIA_PLATFORM_SUPPORT=y in order to have the CONFIG_VIDEO_ASPEED
driver enabled.

Fixes: 06b93644f4d1 ("media: Kconfig: add an option to filter in/out platform 
drivers")
Fixes: b0cd4fb27665 ("media: Kconfig: on !EMBEDDED && !EXPERT, enable driver 
filtering")
Cc: sta...@vger.kernel.org
CC: Mauro Carvalho Chehab 
Signed-off-by: Joel Stanley 
---

Another solution would be to revert b0cd4fb27665 ("media: Kconfig: on
!EMBEDDED && !EXPERT, enable driver filtering"). I assume this was done
to be helpful, but in practice it has enabled the TUNER drivers (and
others) for the following configs that didn't have them before:

$ git grep -lE "(CONFIG_EXPERT|CONFIG_EMBEDDED)"  arch/*/configs/ | xargs grep 
-l MEDIA_SUPPORT
arch/arm/configs/aspeed_g4_defconfig
arch/arm/configs/aspeed_g5_defconfig
arch/arm/configs/at91_dt_defconfig
arch/arm/configs/bcm2835_defconfig
arch/arm/configs/davinci_all_defconfig
arch/arm/configs/ezx_defconfig
arch/arm/configs/imote2_defconfig
arch/arm/configs/imx_v4_v5_defconfig
arch/arm/configs/imx_v6_v7_defconfig
arch/arm/configs/milbeaut_m10v_defconfig
arch/arm/configs/multi_v7_defconfig
arch/arm/configs/omap2plus_defconfig
arch/arm/configs/pxa_defconfig
arch/arm/configs/qcom_defconfig
arch/arm/configs/sama5_defconfig
arch/arm/configs/tegra_defconfig
arch/mips/configs/ci20_defconfig
arch/mips/configs/lemote2f_defconfig
arch/mips/configs/loongson3_defconfig
arch/mips/configs/pistachio_defconfig

I've cc'd the maintainers of these defconfigs so they are aware.

---
 arch/arm/configs/aspeed_g4_defconfig | 3 ++-
 arch/arm/configs/aspeed_g5_defconfig | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/aspeed_g4_defconfig 
b/arch/arm/configs/aspeed_g4_defconfig
index 303f75a3baec..58d293b63581 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -160,7 +160,8 @@ CONFIG_SENSORS_TMP421=y
 CONFIG_SENSORS_W83773G=y
 CONFIG_WATCHDOG_SYSFS=y
 CONFIG_MEDIA_SUPPORT=y
-CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_SUPPORT_FILTER=y
+CONFIG_MEDIA_PLATFORM_SUPPORT=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_VIDEO_ASPEED=y
 CONFIG_DRM=y
diff --git a/arch/arm/configs/aspeed_g5_defconfig 
b/arch/arm/configs/aspeed_g5_defconfig
index b0d056d49abe..cc2449ed6e6d 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -175,7 +175,8 @@ CONFIG_SENSORS_TMP421=y
 CONFIG_SENSORS_W83773G=y
 CONFIG_WATCHDOG_SYSFS=y
 CONFIG_MEDIA_SUPPORT=y
-CONFIG_MEDIA_CAMERA_SUPPORT=y
+CONFIG_MEDIA_SUPPORT_FILTER=y
+CONFIG_MEDIA_PLATFORM_SUPPORT=y
 CONFIG_V4L_PLATFORM_DRIVERS=y
 CONFIG_VIDEO_ASPEED=y
 CONFIG_DRM=y
-- 
2.28.0

Re: [PATCH v2 3/6] netlink/compat: Append NLMSG_DONE/extack to frag_list

[Johannes Berg]

On Wed, 2020-08-26 at 02:49 +0100, Dmitry Safonov wrote:
> Modules those use netlink may supply a 2nd skb, (via frag_list)
> that contains an alternative data set meant for applications
> using 32bit compatibility mode.

Do note, however, that until this day the facility here was only used by
(and originally intended for) wireless extensions, where it exclusively
applies to *event* messages. Hence, we really didn't worry about dump or
any other kind of netlink usage.

That said, it's really just a historic note explaining why it didn't
work for you out of the box :)

> In such a case, netlink_recvmsg will use this 2nd skb instead of the
> original one.
> 
> Without this patch, such compat applications will retrieve
> all netlink dump data, but will then get an unexpected EOF.
> 
> Cc: Johannes Berg 
> Signed-off-by: Florian Westphal 
> Signed-off-by: Dmitry Safonov 
> ---
>  net/netlink/af_netlink.c | 48 
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index b5f30d7d30d0..b096f2b4a50d 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -2186,13 +2186,36 @@ EXPORT_SYMBOL(__nlmsg_put);
>   * It would be better to create kernel thread.
>   */
>  
> +static int netlink_dump_done(struct netlink_sock *nlk, struct sk_buff *skb,
> +  struct netlink_callback *cb,
> +  struct netlink_ext_ack *extack)
> +{
> + struct nlmsghdr *nlh;
> +
> + nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, 
> sizeof(nlk->dump_done_errno),
> +NLM_F_MULTI | cb->answer_flags);
> + if (WARN_ON(!nlh))
> + return -ENOBUFS;
> +
> + nl_dump_check_consistent(cb, nlh);
> + memcpy(nlmsg_data(nlh), &nlk->dump_done_errno,
> + sizeof(nlk->dump_done_errno));

nit: indentation here looks odd.

Other than that, looks reasonable to me.

Reviewed-by: Johannes Berg 

johannes

Re: [PATCH 1/2] i2c: consider devices with of_match_table during i2c device probing

[kernel test robot]

Hi Sergey,

I love your patch! Yet something to improve:

[auto build test ERROR on v5.9-rc2]
[also build test ERROR on next-20200825]
[cannot apply to wsa/i2c/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sergey-Senozhatsky/i2c-consider-devices-with-of_match_table-during-i2c-device-probing/20200826-123138
base:d012a7190fc1fd72ed48911e77ca97ba4521bccd
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=sh 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   sh4-linux-ld: drivers/i2c/i2c-core-smbus.o: in function 
`i2c_acpi_match_device':
>> (.text+0x2400): multiple definition of `i2c_acpi_match_device'; 
>> drivers/i2c/i2c-core-base.o:(.text+0x3260): first defined here
   sh4-linux-ld: drivers/i2c/i2c-core-slave.o: in function 
`i2c_acpi_match_device':
   (.text+0x2c0): multiple definition of `i2c_acpi_match_device'; 
drivers/i2c/i2c-core-base.o:(.text+0x3260): first defined here
   sh4-linux-ld: drivers/i2c/i2c-core-of.o: in function `i2c_acpi_match_device':
   (.text+0x600): multiple definition of `i2c_acpi_match_device'; 
drivers/i2c/i2c-core-base.o:(.text+0x3260): first defined here

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


.config.gz
Description: application/gzip

Re: [PATCH RESEND] fs: Move @f_count to different cacheline with @f_mode

[Shaokun Zhang]

Hi Will，

在 2020/8/22 0:02, Will Deacon 写道:
> On Wed, Jun 24, 2020 at 04:32:28PM +0800, Shaokun Zhang wrote:
>> get_file_rcu_many, which is called by __fget_files, has used
>> atomic_try_cmpxchg now and it can reduce the access number of the global
>> variable to improve the performance of atomic instruction compared with
>> atomic_cmpxchg. 
>>
>> __fget_files does check the @f_mode with mask variable and will do some
>> atomic operations on @f_count, but both are on the same cacheline.
>> Many CPU cores do file access and it will cause much conflicts on @f_count. 
>> If we could make the two members into different cachelines, it shall relax
>> the siutations.
>>
>> We have tested this on ARM64 and X86, the result is as follows:
>> Syscall of unixbench has been run on Huawei Kunpeng920 with this patch:
>> 24 x System Call Overhead  1
>>
>> System Call Overhead3160841.4 lps   (10.0 s, 1 samples)
>>
>> System Benchmarks Partial Index  BASELINE   RESULTINDEX
>> System Call Overhead  15000.03160841.4   2107.2
>>
>> System Benchmarks Index Score (Partial Only) 2107.2
>>
>> Without this patch:
>> 24 x System Call Overhead  1
>>
>> System Call Overhead456.0 lps   (10.0 s, 1 samples)
>>
>> System Benchmarks Partial Index  BASELINE   RESULTINDEX
>> System Call Overhead  15000.0456.0   1481.6
>>
>> System Benchmarks Index Score (Partial Only) 1481.6
>>
>> And on Intel 6248 platform with this patch:
>> 40 CPUs in system; running 24 parallel copies of tests
>>
>> System Call Overhead4288509.1 lps   (10.0 s, 1 
>> samples)
>>
>> System Benchmarks Partial Index  BASELINE   RESULTINDEX
>> System Call Overhead  15000.04288509.1   2859.0
>>
>> System Benchmarks Index Score (Partial Only) 2859.0
>>
>> Without this patch:
>> 40 CPUs in system; running 24 parallel copies of tests
>>
>> System Call Overhead3666313.0 lps   (10.0 s, 1 
>> samples)
>>
>> System Benchmarks Partial Index  BASELINE   RESULTINDEX
>> System Call Overhead  15000.03666313.0   2444.2
>>
>> System Benchmarks Index Score (Partial Only) 2444.2
>>
>> Cc: Will Deacon 
>> Cc: Mark Rutland 
>> Cc: Peter Zijlstra 
>> Cc: Alexander Viro 
>> Cc: Boqun Feng 
>> Signed-off-by: Yuqi Jin 
>> Signed-off-by: Shaokun Zhang 
>> ---
>>  include/linux/fs.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 3f881a892ea7..0faeab5622fb 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -955,7 +955,6 @@ struct file {
>>   */
>>  spinlock_t  f_lock;
>>  enum rw_hintf_write_hint;
>> -atomic_long_t   f_count;
>>  unsigned intf_flags;
>>  fmode_t f_mode;
>>  struct mutexf_pos_lock;
>> @@ -979,6 +978,7 @@ struct file {
>>  struct address_space*f_mapping;
>>  errseq_tf_wb_err;
>>  errseq_tf_sb_err; /* for syncfs */
>> +atomic_long_t   f_count;
>>  } __randomize_layout
>>__attribute__((aligned(4)));  /* lest something weird decides that 2 
>> is OK */
> 
> Hmm. So the microbenchmark numbers look lovely, but:

Thanks,

> 
>   - What impact does it actually have for real workloads?

It is exposed by we do the unixbench test. About the real workloads, if it has 
many
threads and open the same file, it shall be useful like unixbench.
If not the scenes, it should not be regression with the patch because we only 
change
the poistion of @f_count with @f_mode.

>   - How do we avoid regressing performance by innocently changing the struct
> again later on?

It shall be commented this change on the @f_count, I'm not sure it is enough.

>   - This thing is tagged with __randomize_layout, so it doesn't help anybody
> using that crazy plugin

This patch isolated the @f_count with @f_mode absolutely and we don't care the
base address of the structure, or I may miss something what you said.

>   - What about all the other atomics and locks that share cachelines?

An interesting question, to be honest, about this issue, we did performance
profile using unixbench and found it, then we want to relax the conflicts.
For other scenes, this method may be useful if it is debugged by the same
conflicts, but it can't be detected automatically.

Thanks,
Shaokun

> 
> Will

Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge

[Tomi Valkeinen]

Hi,

On 11/08/2020 05:36, Laurent Pinchart wrote:
>> +{
>> +u32 max_bw, req_bw, bpp;
>> +
>> +bpp = cdns_mhdp_get_bpp(&mhdp->display_fmt);
>> +req_bw = mode->clock * bpp / 8;
>> +max_bw = lanes * rate;
> mode->clock is in kHz, while rate is expressed in 10kHz unit if I'm not
> mistaken.

Rate is in 10 kbps units. And 10 bits in DP gives you one byte (8b/10b 
encoding). So max_bw is in
kBps, the same as req_bw.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[PATCH v1] scsi: libsas: set data_dir as DMA_NONE if libata mark qc as NODATA

[Luo Jiaxing]

We found that it will fail every time when set feature to SATA disk by
"sdparm -s WCE=0 /dev/sde".

After checking protocol, we know that MODE SELECT is the SCSI command for
setting WCE, and it do not exist in the SATA protocol. Therefore, this
commands are encapsulated in the SET FEATURE command in SATA protocol.
The difference is that the MODE SELECT command sent to SAS disk contains
data and is sent through the DMA. But when send to SATA disk through
SET FEATURE command, it does not contain data.

I think libsas was not thorough enough in dealing with the situation, at
sas_ata_qc_issue(), task->dma_dir is inherited from qc->dma_dir(qc->dma_dir
is also inherited from SCSI). However, in ATA driver, if qc->tf.protocol is
set to ATA_PROT_NODATA, ata_sg_setup() will not invoked by ata_qc_issue().
It mean that ATA didn't use dma_dir and it's not reliable. So, if libsas
still inherits from qc->dma_dir when there is no data need to be send. As a
result, task with no data are mistakenly considered as carrying data and it
will make LLDD report an error on IO completion.

So, When ATA driver mark tf->protocol as NODATA, dma_dir should be set as
DMA_NONE. And we can see WCE is successfully disable for SATA disk then.

Euler:~ # sdparm -s WCE=0 /dev/sde
 /dev/sde: ATA   ST4000NM0035-1V4  TN03
Euler:~ # sdparm /dev/sde
 /dev/sde: ATA   ST4000NM0035-1V4  TN03
Read write error recovery mode page:
   AWRE1  [cha: n, def:  1]
   ARRE0  [cha: n, def:  0]
   PER 0  [cha: n, def:  0]
Caching (SBC) mode page:
   WCE 0  [cha: y, def:  0]
   RCD 0  [cha: n, def:  0]
Control mode page:
   SWP 0  [cha: n, def:  0]

Fixes: fa1c1e8f1ece ("[SCSI] Add SATA support to libsas")

Signed-off-by: Luo Jiaxing 
Reviewed-by: John Garry 
---
 drivers/scsi/libsas/sas_ata.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 6a521ba..a488798 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -209,7 +209,10 @@ static unsigned int sas_ata_qc_issue(struct ata_queued_cmd 
*qc)
task->num_scatter = si;
}
 
-   task->data_dir = qc->dma_dir;
+   if (qc->tf.protocol == ATA_PROT_NODATA)
+   task->data_dir = DMA_NONE;
+   else
+   task->data_dir = qc->dma_dir;
task->scatter = qc->sg;
task->ata_task.retry_count = 1;
task->task_state_flags = SAS_TASK_STATE_PENDING;
-- 
2.7.4

Re: [PATCH] MAINTAINERS: add namespace entry

[Aleksa Sarai]

On 2020-08-25, Eric W. Biederman  wrote:
> C) You have overstated what I have agreed to here.
>I have have previously said that I agree that having a MAINTAINERS
>entry so people who are unfamiliar with the situation with namespaces
>can find us.  Given that most of the changes going forward are likely
>to be maintenance changes.
> 
>I also said we need to talk about how we plan to maintain the code
>here.
> 
>It feels like you are pushing this hard, and I am not certain why you
>are pushing and rushing this.  With my maintainer hat on my big
>concern is we catch the issues that will introduce security issue.
>Recently I have seen a report that there is an issue on Ubuntu
>kernels where anyone can read /etc/shadow.  The problem is that
>Ubuntu has not been cautions and has not taken the time to figure out
>how to enable things for unprivileged users safely, and have just
>enabled the code to be used by unprivileged users because it is
>useful.
> 
>In combination with you pushing hard and not taking the time to
>complete this conversation in private with me, this MAINTAINERS entry
>makes me uneasy as it feels like you may be looking for a way to push
>the code into the mainline kernel like has been pushed into the
>Ubuntu kernel.  I may be completely wrong I just don't know what to
>make of your not finishing our conversation in private, and forcing
>my hand by posting this patch publicly.

Eric, with all due respect, Christian is not a sleeper agent of some
shadow Ubuntu kernel team that is tirelessly trying to slip things by
you. I have no idea where you could have possibly gotten this
impression, given his track record of the past few years.

I also don't understand why you feel the need to talk about things which
he had nothing to do with -- what relationship does the /etc/shadow
thing have to do with his work and track record? Were Debian kernel
contributors considered untrustworthy because of the OpenSSL weak keys
issue? Would it be fair to question your competence because some RHEL
kernel backports were borked? Of course not -- that would be ridiculous!

> At the same time I am not convinced you are actually going to do the
> work to make new code maintainable and not a problem for other kernel
> developers.
> 
> A big part the job over the years has been to make the namespace ideas
> proposed sane, and to keep the burden from other maintainers of naive
> and terrible code.  Pushing this change before we finished our private
> conversation makes me very nervous on that front.

What gives you that impression? This whole thing seems incredibly
strange -- we've all met IRL several times, and have had many long
discussions about the best way to solve problems without placing undue
burden on kernel maintenance.

Furthermore, I don't think this is an acceptable way to talk about a
peer within the kernel community -- attributing malicious intent without
any justification other than "I feel this is the case" is little more
than a character assassination, and I don't see why you would feel that
such a statement is justified.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

[PATCH] mm: memcg: Fix memcg reclaim soft lockup

[Xunlei Pang]

We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
the target memcg doesn't have any reclaimable memory.

It can be easily reproduced as below:
 watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204]
 CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12
 Call Trace:
  shrink_lruvec+0x49f/0x640
  shrink_node+0x2a6/0x6f0
  do_try_to_free_pages+0xe9/0x3e0
  try_to_free_mem_cgroup_pages+0xef/0x1f0
  try_charge+0x2c1/0x750
  mem_cgroup_charge+0xd7/0x240
  __add_to_page_cache_locked+0x2fd/0x370
  add_to_page_cache_lru+0x4a/0xc0
  pagecache_get_page+0x10b/0x2f0
  filemap_fault+0x661/0xad0
  ext4_filemap_fault+0x2c/0x40
  __do_fault+0x4d/0xf9
  handle_mm_fault+0x1080/0x1790

It only happens on our 1-vcpu instances, because there's no chance
for oom reaper to run to reclaim the to-be-killed process.

Add cond_resched() in such cases at the beginning of shrink_lruvec()
to give up the cpu to others.

Signed-off-by: Xunlei Pang 
---
 mm/vmscan.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 99e1796..349a88e 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2449,6 +2449,12 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
scan_adjusted = (!cgroup_reclaim(sc) && !current_is_kswapd() &&
 sc->priority == DEF_PRIORITY);
 
+   /* memcg reclaim may run into no reclaimable lru pages */
+   if (nr[LRU_ACTIVE_FILE] == 0 &&
+   nr[LRU_INACTIVE_FILE] == 0 &&
+   nr[LRU_INACTIVE_ANON] == 0)
+   cond_resched();
+
blk_start_plug(&plug);
while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
nr[LRU_INACTIVE_FILE]) {
-- 
1.8.3.1

[PATCH] docs: trace: ring-buffer-design.rst: use the new SPDX tag

[Mauro Carvalho Chehab]

SPDX v3.10 gained support for GFDL-1.2 with no invariant sections:

https://spdx.org/licenses/GFDL-1.2-invariants-only.html

Let's use it, instead of keeping a license text for this file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/trace/ring-buffer-design.rst | 26 +-
 1 file changed, 1 insertion(+), 25 deletions(-)

diff --git a/Documentation/trace/ring-buffer-design.rst 
b/Documentation/trace/ring-buffer-design.rst
index 9c8d22a53d6c..a76435610b58 100644
--- a/Documentation/trace/ring-buffer-design.rst
+++ b/Documentation/trace/ring-buffer-design.rst
@@ -1,28 +1,4 @@
-.. This file is dual-licensed: you can use it either under the terms
-.. of the GPL 2.0 or the GFDL 1.2 license, at your option. Note that this
-.. dual licensing only applies to this file, and not this project as a
-.. whole.
-..
-.. a) This file is free software; you can redistribute it and/or
-..modify it under the terms of the GNU General Public License as
-..published by the Free Software Foundation version 2 of
-..the License.
-..
-..This file is distributed in the hope that it will be useful,
-..but WITHOUT ANY WARRANTY; without even the implied warranty of
-..MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-..GNU General Public License for more details.
-..
-.. Or, alternatively,
-..
-.. b) Permission is granted to copy, distribute and/or modify this
-..document under the terms of the GNU Free Documentation License,
-..Version 1.2 version published by the Free Software
-..Foundation, with no Invariant Sections, no Front-Cover Texts
-..and no Back-Cover Texts. A copy of the license is included at
-..Documentation/userspace-api/media/fdl-appendix.rst.
-..
-.. TODO: replace it to GPL-2.0 OR GFDL-1.2 WITH no-invariant-sections
+.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.2-invariants-only
 
 ===
 Lockless Ring Buffer Design
-- 
2.26.2

Re: [PATCH 2/5] Add manpages for move_mount(2) and open_tree(2)

[Michael Kerrisk (man-pages)]

On 8/24/20 12:08 PM, David Howells wrote:
> Michael Kerrisk (man-pages)  wrote:
> 
>>> +To access the source mount object or the destination mountpoint, no
>>> +permissions are required on the object itself, but if either pathname is
>>> +supplied, execute (search) permission is required on all of the directories
>>> +specified in
>>> +.IR from_pathname " or " to_pathname .
>>> +.PP
>>> +The caller does, however, require the appropriate capabilities or 
>>> permission
>>> +to effect a mount.
>>
>> Maybe better: s/effect/create/
> 
> The mount has already been created.  We're moving/attaching it.  

Ahh -- then the verb was wrong.

to effect == to cause, bring about
to affect == to change, have an impact on

> Maybe:
> 
>   The caller does, however, require the appropriate privilege (Linux:
>   the CAP_SYS_ADMIN capability) to move or attach mounts.

Yes, better.

Thanks,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

RE: [PATCH v3] exfat: integrates dir-entry getting and validation

[Namjae Jeon]

> Thank you for quick reply!
> 
> On 2020/08/26 13:19, Namjae Jeon wrote:
> >> On 2020/08/26 10:03, Namjae Jeon wrote:
>  Second: Range validation and type validation should not be separated.
>  When I started making this patch, I intended to add only range 
>  validation.
>  However, after the caller gets the ep, the type validation follows.
>  Get ep, null check of ep (= range verification), type verification is a 
>  series of procedures.
>  There would be no reason to keep them independent anymore.
>  Range and type validation is enforced when the caller uses ep.
> >>> You can add a validate flags as argument of exfat_get_dentry_set(), e.g. 
> >>> none, basic and strict.
> >>> none : only range validation.
> >>> basic : range + type validation.
> >>> strict : range + type + checksum and name length, etc.
> >>
> >> Currently, various types of verification will not be needed.
> >> Let's add it when we need it.
> >>>
> > -   /* validiate cached dentries */
> > -   for (i = 1; i < num_entries; i++) {
> > -   ep = exfat_get_dentry_cached(es, i);
> > -   if (!exfat_validate_entry(exfat_get_entry_type(ep), 
> > &mode))
> > +   ep = exfat_get_dentry_cached(es, ENTRY_STREAM);
> > +   if (!ep || ep->type != EXFAT_STREAM)
> > +   goto free_es;
> > +   es->de[ENTRY_STREAM] = ep;
> 
>  The value contained in stream-ext dir-entry should not be used
>  before validating the EntrySet
> >> checksum.
>  So I would insert EntrySet checksum validation here.
>  In that case, the checksum verification loop would be followed by
>  the TYPE_NAME verification loop, can you acceptable?
> >>> Yes. That would be great.
> >>
> >> OK.
> >> I'll add TYPE_NAME verification after checksum verification, in next patch.
> >> However, I think it is enough to validate TYPE_NAME when extracting name.
> >> Could you please tell me why you think you need TYPE_NAME validation here?
> > I've told you on previous mail. This function should return validated
> > dentry set after checking
> > file->stream->name in sequence.
> 
> Yes. I understand that the current implementation checks in that order.
> Sorry, my question was unclear.
> Why do you think you should leave the TYPE_NAME validation in this function?
> What kind of problem are you worried about if this function does not validate 
> TYPE_NAME?
> (for preserve the current behavior?)
We have not checked the problem when it is removed because it was implemented
according to the specification from the beginning. And your v3 patch are
already checking the name entries as TYPE_SECONDARY. And it check them with
TYPE_NAME again in exfat_get_uniname_from_ext_entry(). If you check TYPE_NAME
with stream->name_len, We don't need to perform the loop for extracting
filename from the name entries if stream->name_len or name entry is invalid.

And I request to prove why we do not need to validate name entries in this
function calling from somewhere. So as I suggested earlier, You can make it
with an argument flags so that we skip the validation.
> 
> Don't worry, I will add TYPE_NAME verification to the v4 patch.
> I will post it later today.
Sound good.
> 
> BR
> ---
> Tetsuhiro Kohada 

Re: [PATCH v1 2/9] extcon: extcon-ptn5150: Switch to GENMASK() for VBUS detection macro

[Ramuthevar, Vadivel MuruganX]

Hi,

On 26/8/2020 2:59 pm, Krzysztof Kozlowski wrote:

On Tue, Aug 18, 2020 at 02:57:20PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Switch to GENMASK() for VBUS detection macro.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
  drivers/extcon/extcon-ptn5150.c | 9 +++--
  1 file changed, 3 insertions(+), 6 deletions(-)


This is too simple change, should be squashed with 1, 3, 4 and 5.

There is no point to split each change a define to use BIT or GENMASK.

Thank you for the review comments and suggestions.
Sure, I will squash it as mentioned patches mentioned above.

Best Regards
Vadivel


Best regards,
Krzysztof



diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 5d9a8767646b..c816a6c1e05c 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -42,9 +42,7 @@ enum ptn5150_reg {
  #define PTN5150_REG_CC_PORT_ATTACHMENT_MASK   \
(0x7 << PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT)
  
-#define PTN5150_REG_CC_VBUS_DETECTION_SHIFT	7

-#define PTN5150_REG_CC_VBUS_DETECTION_MASK \
-   (0x1 << PTN5150_REG_CC_VBUS_DETECTION_SHIFT)
+#define PTN5150_REG_CC_VBUS_DETECTION  BIT(7)
  
  #define PTN5150_REG_INT_CABLE_ATTACH_SHIFT	0

  #define PTN5150_REG_INT_CABLE_ATTACH_MASK \
@@ -130,9 +128,8 @@ static void ptn5150_irq_work(struct work_struct *work)
case PTN5150_UFP_ATTACHED:
extcon_set_state_sync(info->edev, EXTCON_USB,
false);
-   vbus = ((reg_data &
-   PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
-   PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
+   vbus = FIELD_GET(PTN5150_REG_CC_VBUS_DETECTION,
+reg_data);
if (vbus)
gpiod_set_value(info->vbus_gpiod, 0);
else
--
2.11.0

Re: [PATCH v2] nvmem: mtk-efuse: Remove EFUSE register write support

[CK Hu]

Hi, Chih-En:

On Wed, 2020-08-26 at 14:21 +0800, Chih-En Hsu wrote:
> This patch is to remove function "mtk_reg_write" since
> Mediatek EFUSE hardware only supports read functionality
> for NVMEM consumers.
> 

Reviewed-by: CK Hu 

> Fixes: 4c7e4fe37766 ("nvmem: mediatek: Add Mediatek EFUSE driver")
> Signed-off-by: Chih-En Hsu 
> ---
>  drivers/nvmem/mtk-efuse.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 856d9c3fc38e..6a537d959f14 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
>   return 0;
>  }
>  
> -static int mtk_reg_write(void *context,
> -  unsigned int reg, void *_val, size_t bytes)
> -{
> - struct mtk_efuse_priv *priv = context;
> - u32 *val = _val;
> - int i = 0, words = bytes / 4;
> -
> - while (words--)
> - writel(*val++, priv->base + reg + (i++ * 4));
> -
> - return 0;
> -}
> -
>  static int mtk_efuse_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>   econfig.stride = 4;
>   econfig.word_size = 4;
>   econfig.reg_read = mtk_reg_read;
> - econfig.reg_write = mtk_reg_write;
>   econfig.size = resource_size(res);
>   econfig.priv = priv;
>   econfig.dev = dev;

RE: [PATCH 00/13] lib/generic-radix-tree: genradix bug fix and optimisations.

[David Laight]

From: Kent Overstreet
> Sent: 25 August 2020 17:32
> 
> On Tue, Aug 25, 2020 at 04:00:35PM +, David Laight wrote:
> > From: 'Marcelo Ricardo Leitner'
> > > Sent: 25 August 2020 16:41
> > >
> > > On Tue, Aug 25, 2020 at 02:52:34PM +, David Laight wrote:
> > > > The genradix code is used by SCTP for accessing per-stream data.
> > > > This means there are quite a lot of lookups but the code wasn't
> > > > really optimised at all.
> > >
> > > My test box is down for the moment and will bring it on later today or
> > > tomorrow, so I can't test it yet. What should we expect as performance
> > > gains here?
> >
> > Not sure, probably not much, but it ought to show up :-)
> > There'll be bigger gains on a cpu that has software ilog2().
> >
> > I've only checked SCTP still works.
> > I've requested 32k streams on a listener - to force a level-2 tree.
> > I've also done at least one check with a massive pad in the sctp
> > stream structure.
> 
> Have you benchmarked at all? Or were you looking at the generated assembly?

I've been reading a lot of assembly.
(Some of the code generated by modern gcc is crap.)
With horrible casts it is the easiest way to check the code is right!

I'm going to try marking the lookup functions with '__attribute__ ((pure))'.
That should help the sctp code that does repeated SCTP_SI().
In reality I want to mark them __attribute__ ((const)) - including the
inline wrappers, but that isn't allowed if they read memory.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH 8/9] rpmsg: virtio: use rpmsg_ns driver to manage ns announcement

[Arnaud POULIQUEN]

Hi mathieu,

I Sent my V2 few seconds before receiving your comment :)
Please find my answer below

On 8/25/20 6:54 PM, Mathieu Poirier wrote:
> Hi Arnaud,
> 
> On Fri, Jul 31, 2020 at 01:47:31PM +0200, Arnaud Pouliquen wrote:
>> Use the new rpmsg_ns API to send the name service announcements if
>> the VIRTIO_RPMSG_F_NS is set, else just not implement the ops.
>>
>> Signed-off-by: Arnaud Pouliquen 
>> ---
>>  drivers/rpmsg/virtio_rpmsg_bus.c | 94 +---
>>  1 file changed, 13 insertions(+), 81 deletions(-)
>>
>> diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
>> b/drivers/rpmsg/virtio_rpmsg_bus.c
>> index f771fdae150e..3c771a6392be 100644
>> --- a/drivers/rpmsg/virtio_rpmsg_bus.c
>> +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
>> @@ -91,35 +91,6 @@ struct rpmsg_hdr {
>>  u8 data[];
>>  } __packed;
>>  
>> -/**
>> - * struct rpmsg_ns_msg - dynamic name service announcement message
>> - * @name: name of remote service that is published
>> - * @addr: address of remote service that is published
>> - * @flags: indicates whether service is created or destroyed
>> - *
>> - * This message is sent across to publish a new service, or announce
>> - * about its removal. When we receive these messages, an appropriate
>> - * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
>> - * or ->remove() handler of the appropriate rpmsg driver will be invoked
>> - * (if/as-soon-as one is registered).
>> - */
>> -struct rpmsg_ns_msg {
>> -char name[RPMSG_NAME_SIZE];
>> -__virtio32 addr;
>> -__virtio32 flags;
>> -} __packed;
>> -
>> -/**
>> - * enum rpmsg_ns_flags - dynamic name service announcement flags
>> - *
>> - * @RPMSG_NS_CREATE: a new remote service was just created
>> - * @RPMSG_NS_DESTROY: a known remote service was just destroyed
>> - */
>> -enum rpmsg_ns_flags {
>> -RPMSG_NS_CREATE = 0,
>> -RPMSG_NS_DESTROY= 1,
>> -};
>> -
>>  /**
>>   * @vrp: the remote processor this channel belongs to
>>   */
>> @@ -324,60 +295,18 @@ static void virtio_rpmsg_destroy_ept(struct 
>> rpmsg_endpoint *ept)
>>  __rpmsg_destroy_ept(vch->vrp, ept);
>>  }
>>  
>> -static int virtio_rpmsg_announce_create(struct rpmsg_device *rpdev)
>> -{
>> -struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>> -struct virtproc_info *vrp = vch->vrp;
>> -struct device *dev = &rpdev->dev;
>> -int err = 0;
>> -
>> -/* need to tell remote processor's name service about this channel ? */
>> -if (rpdev->announce && rpdev->ept &&
>> -virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
>> -struct rpmsg_ns_msg nsm;
>> -
>> -strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
>> -nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
>> -nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_CREATE);
>> -
>> -err = rpmsg_sendto(rpdev->ept, &nsm, sizeof(nsm), 
>> RPMSG_NS_ADDR);
>> -if (err)
>> -dev_err(dev, "failed to announce service %d\n", err);
>> -}
>> -
>> -return err;
>> -}
>> -
>> -static int virtio_rpmsg_announce_destroy(struct rpmsg_device *rpdev)
>> -{
>> -struct virtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev);
>> -struct virtproc_info *vrp = vch->vrp;
>> -struct device *dev = &rpdev->dev;
>> -int err = 0;
>> -
>> -/* tell remote processor's name service we're removing this channel */
>> -if (rpdev->announce && rpdev->ept &&
>> -virtio_has_feature(vrp->vdev, VIRTIO_RPMSG_F_NS)) {
>> -struct rpmsg_ns_msg nsm;
>> -
>> -strncpy(nsm.name, rpdev->id.name, RPMSG_NAME_SIZE);
>> -nsm.addr = cpu_to_virtio32(vrp->vdev, rpdev->ept->addr);
>> -nsm.flags = cpu_to_virtio32(vrp->vdev, RPMSG_NS_DESTROY);
>> -
>> -err = rpmsg_sendto(rpdev->ept, &nsm, sizeof(nsm), 
>> RPMSG_NS_ADDR);
>> -if (err)
>> -dev_err(dev, "failed to announce service %d\n", err);
>> -}
>> -
>> -return err;
>> -}
>> -
>>  static const struct rpmsg_device_ops virtio_rpmsg_ops = {
>>  .create_channel = virtio_rpmsg_create_channel,
>>  .release_channel = virtio_rpmsg_release_channel,
>>  .create_ept = virtio_rpmsg_create_ept,
>> -.announce_create = virtio_rpmsg_announce_create,
>> -.announce_destroy = virtio_rpmsg_announce_destroy,
>> +};
>> +
>> +static const struct rpmsg_device_ops virtio_rpmsg_w_nsa_ops = {
>> +.create_channel = virtio_rpmsg_create_channel,
>> +.release_channel = virtio_rpmsg_release_channel,
>> +.create_ept = virtio_rpmsg_create_ept,
>> +.announce_create = rpmsg_ns_announce_create,
>> +.announce_destroy = rpmsg_ns_announce_destroy,
>>  };
>>  
>>  static void virtio_rpmsg_release_device(struct device *dev)
>> @@ -423,7 +352,10 @@ __rpmsg_create_channel(struct virtproc_info *vrp,
>>  rpdev = &vch->rpdev;
>>  rpdev->src = chinfo->src;
>>  rpdev->dst = chinfo->dst;
>> -rp

RE: [PATCH 3/3] usb: cdns3: Enable workaround for USB2.0 PHY Rx compliance test PHY lockup

[Pawel Laszczak]

>
>On 20-08-26 04:04:01, Pawel Laszczak wrote:
>> >On 20-08-25 15:00:59, Roger Quadros wrote:
>> >> From: Pawel Laszczak 
>> >>
>> >> USB2.0 PHY hangs in Rx Compliance test when the incoming packet
>> >> amplitude is varied below and above the Squelch Level of
>> >> Receiver during the active packet multiple times.
>> >>
>> >> Version 1 of the controller allows PHY to be reset when RX fail condition
>> >> is detected to work around the above issue. This feature is
>> >> disabled by default and needs to be enabled using a bit from
>> >> the newly added PHYRST_CFG register. This patch enables the workaround.
>> >>
>> >> As there is no way to distinguish between the controller version
>> >> before the device controller is started we need to rely on a
>> >> DT property to decide when to apply the workaround.
>> >
>> >Pawel, it could know the controller version at cdns3_gadget_start,
>> >but the controller starts when it tries to bind gadget driver, at that
>> >time, it has already known the controller version.
>> >
>> >For me, the device controller starts is using USB_CONF.DEVEN (Device
>> >Enable) through usb_gadget_connect, I am not sure if it is the same
>> >with yours.
>> >
>>
>> Yes in device mode driver knows controller version but this workaround
>> Must be enabled also in host mode. In host mode the controller
>> doesn't have access to device registers. The controller version is
>> placed in device register.
>>
>
>You may suggest your design team adding CHIP_VER register at global
>register region, it will easy the software engineer life.
>
>From what I read, this register is only enabling USB2 PHY reset software
>control, it needs for all chips with rev 0x0002450D, and the place you
>current change is only for 0x0002450D, right?

Even I could say that this workaround should be enabled only for 
Specific USB2 PHY  (only 0x0002450D)

This bit should not have any impact for Cadence PHY but it can has 
Impact for third party PHYs.
 
Pawel

>
>Peter
>
>> Pawel
>>
>> >Peter
>> >
>> >
>> >>
>> >> Signed-off-by: Pawel Laszczak 
>> >> Signed-off-by: Roger Quadros 
>> >> ---
>> >>  drivers/usb/cdns3/core.c |  2 ++
>> >>  drivers/usb/cdns3/core.h |  1 +
>> >>  drivers/usb/cdns3/drd.c  | 12 
>> >>  drivers/usb/cdns3/drd.h  |  5 -
>> >>  4 files changed, 19 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
>> >> index 5c1586ec7824..34b36487682b 100644
>> >> --- a/drivers/usb/cdns3/core.c
>> >> +++ b/drivers/usb/cdns3/core.c
>> >> @@ -443,6 +443,8 @@ static int cdns3_probe(struct platform_device *pdev)
>> >>   return -ENXIO;
>> >>   }
>> >>
>> >> + cdns->phyrst_a_enable = device_property_read_bool(dev, 
>> >> "cdns,phyrst-a-enable");
>> >> +
>> >>   cdns->otg_res = *res;
>> >>
>> >>   mutex_init(&cdns->mutex);
>> >> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
>> >> index 1ad1f1fe61e9..24cf0f1b5726 100644
>> >> --- a/drivers/usb/cdns3/core.h
>> >> +++ b/drivers/usb/cdns3/core.h
>> >> @@ -76,6 +76,7 @@ struct cdns3 {
>> >>  #define CDNS3_CONTROLLER_V0  0
>> >>  #define CDNS3_CONTROLLER_V1  1
>> >>   u32 version;
>> >> + boolphyrst_a_enable;
>> >>
>> >>   int otg_irq;
>> >>   int dev_irq;
>> >> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
>> >> index 6234bcd6158a..b74803e9703d 100644
>> >> --- a/drivers/usb/cdns3/drd.c
>> >> +++ b/drivers/usb/cdns3/drd.c
>> >> @@ -42,6 +42,18 @@ int cdns3_set_mode(struct cdns3 *cdns, enum 
>> >> usb_dr_mode mode)
>> >>   reg = readl(&cdns->otg_v1_regs->override);
>> >>   reg |= OVERRIDE_IDPULLUP;
>> >>   writel(reg, &cdns->otg_v1_regs->override);
>> >> +
>> >> + /*
>> >> +  * Enable work around feature built into the
>> >> +  * controller to address issue with RX Sensitivity
>> >> +  * est (EL_17) for USB2 PHY. The issue only occures
>> >> +  * for 0x0002450D controller version.
>> >> +  */
>> >> + if (cdns->phyrst_a_enable) {
>> >> + reg = readl(&cdns->otg_v1_regs->phyrst_cfg);
>> >> + reg |= PHYRST_CFG_PHYRST_A_ENABLE;
>> >> + writel(reg, &cdns->otg_v1_regs->phyrst_cfg);
>> >> + }
>> >>   } else {
>> >>   reg = readl(&cdns->otg_v0_regs->ctrl1);
>> >>   reg |= OVERRIDE_IDPULLUP_V0;
>> >> diff --git a/drivers/usb/cdns3/drd.h b/drivers/usb/cdns3/drd.h
>> >> index 7e7cf7fa2dd3..f1ccae285a16 100644
>> >> --- a/drivers/usb/cdns3/drd.h
>> >> +++ b/drivers/usb/cdns3/drd.h
>> >> @@ -31,7 +31,7 @@ struct cdns3_otg_regs {
>> >>   __le32 simulate;
>> >>   __le32 override;
>> >>   __le32 susp_ctrl;
>> >> - __le32 reserved4;
>> >> + __le32 phyrst_cfg;
>> >>   __le32 anasts;
>> 

Re: [PATCH v2 11/17] clk: imx: Add blk_ctrl combo driver

[Philipp Zabel]

On Tue, 2020-08-25 at 21:30 +0300, Abel Vesa wrote:
[...]
> > if (assert)
> > pm_runtime_get_sync();
> > spin_lock_irqsave();
> > /* ... */
> > spin_unlock_irqrestore();
> > if (assert && asserted_before)
> > pm_runtime_put();
> > 
> 
> On a second thought this doesn't work because, for the first assertion,
> the runtime put will never be called, if the asserted_before does not count
> the current assertion.

I'm not sure I follow. The first assert will increment device usage
0 -> 1, all others asserts will just temporarily increment and decrement
1 -> 2 -> 1. Isn't this just missing one
if (!assert && !asserted_after)
pm_runtime_put()
to do the last deassert 1 -> 0 transition?

> If it counts the current assertion, then every assertion
> will end with runtime put. None of these options work here.
>
> How about the following:
>
>   if (assert && !test_and_set_bit(1, &drvdata->rst_hws[id].asserted)) 
>   pm_runtime_get_sync(rcdev->dev);
> 
>   spin_lock_irqsave(&drvdata->lock, flags);   
> 
>   reg = readl(reg_addr);  
>   if (assert) 
>   writel(reg & ~(mask << shift), reg_addr);   
>   else
>   writel(reg | (mask << shift), reg_addr);
> 
>   spin_unlock_irqrestore(&drvdata->lock, flags);  
> 
>   if (!assert && test_and_clear_bit(1, &drvdata->rst_hws[id].asserted))   
>   pm_runtime_put(rcdev->dev); 
> 
> This would only call the get_sync/put once for each reset bit.

Yes, that should work. I think it is a much better idea, no more looping
through the entire reset control array.

regards
Philipp

Re: [PATCH v1 3/9] extcon: extcon-ptn5150: Switch to BIT() macro for cable attach

[Ramuthevar, Vadivel MuruganX]

Hi,

On 26/8/2020 2:59 pm, Krzysztof Kozlowski wrote:

On Tue, Aug 18, 2020 at 02:57:21PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan

Switch to BIT() macro for the cable attach.

Squash it.

Sure, will squash it and rebase over your patches then send it, thanks!

Best Regards
Vadivel

Re: [PATCH 2/2] dt-bindings: interrupt-controller: Add MStar interrupt controller

[Mark-PK Tsai]

From: Rob Herring 

>> +
>> +  "#interrupt-cells":
>> +const: 3
>> +description: |
>> +  Use the same format as specified by GIC in arm,gic.yaml.
>
>That's odd. You have the same SPI and PPI stuff?
>

No, but I just want to keep the format same as arm,gic, and let the
driver bypass 1st and 3rd cell to the parent GIC.
The mst-intc driver translate the interrupt number in 2nd cell to the
interrupt on the parent GIC.

>> +
>> +  reg:
>> +description: |
>> +  Physical base address of the mstar interrupt controller
>> +  registers and length of memory mapped region.
>
>Drop this. That's every 'reg' property.
>
>> +minItems: 1
>
>maxItems is more logical.
>
>> +
>> +  mstar,irqs-map-range:
>> +description: |
>> +  The range of parent interrupt controller's interrupt lines
>> +  that are hardwired to mstar interrupt controller.
>
>Is this  or ?
>

.
I will add this in the description.

>Really, this should just use 'interrupts' even though that's a bit 
>verbose. Or be implied by the compatible string. What's the maximum 
>number of parent interrupts?
>
>In any case, we really need to stop having vendor specific properties 
>for this.

We use 64 interrupts per interrupt controller.
As you mentions, if we use the standard property 'interrupts',
then we need to put 64 interrupt property in the interrupt
controller node, and it will be hard to understand.
So I suppose we need an vendor specific property here.

>
>> +$ref: /schemas/types.yaml#/definitions/uint32-matrix
>> +items:
>> +  minItems: 2
>> +  maxItems: 2
>> +
>> +  mstar,intc-no-eoi:
>> +description: |
>
>Don't need '|' if there's no formatting.
>
>> +  Mark this controller has no End Of Interrupt(EOI) implementation.
>> +  This is a empty, boolean property.
>
>You can drop this line. The schema says this.
>
>> +type: boolean
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - mstar,irqs-map-range
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +mst_intc0: interrupt-controller@1f2032d0 {
>> +  compatible = "mstar,mst-intc", "mediatek,mt58xx-intc";
>> +  interrupt-controller;
>> +  #interrupt-cells = <3>;
>> +  #address-cells = <1>;
>> +  #size-cells = <1>;
>> +  interrupt-parent = <&gic>;
>> +  reg = <0x1f2032d0 0x30>;
>> +  mstar,irqs-map-range = <0 63>;
>
>Is 0 a PPI or SPI? This property is making some assumption and wouldn't 
>be able to support both types or another parent interrupt controller.
>

0 is the interrupt number of the parent interrupt controller.
There's no SPI and PPI stuff in mst-intc, it will bypass the
1st cell to parent controller.

e.g. The device node as following will point to GIC SPI 31
("value in 2nd cell" + "start in irqs-map-range").
usb: {
interrupt-parent = <&mtk_intc0>;
interrupts = <0x0 31 0x4>;
...
};

>> +};
>> +...
>> -- 
>> 2.18.0

Re: [PATCH 1/2] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings

[mkrishn]

On 2020-08-25 04:27, Rob Herring wrote:

On Mon, Aug 10, 2020 at 07:08:02PM +0530, Krishna Manikandan wrote:

MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
like DPU display controller, DSI etc. Add YAML schema
for the device tree bindings for the same.

Signed-off-by: Krishna Manikandan 

Changes in v2:
- Changed dpu to DPU (Sam Ravnborg)
- Fixed indentation issues (Sam Ravnborg)
- Added empty line between different properties (Sam Ravnborg)
- Replaced reference txt files with  their corresponding
  yaml files (Sam Ravnborg)
- Modified the file to use "|" only when it is
  necessary (Sam Ravnborg)

Changes in v3:
- Corrected the license used (Rob Herring)
- Added maxItems for properties (Rob Herring)
- Dropped generic descriptions (Rob Herring)
- Added ranges property (Rob Herring)
- Corrected the indendation (Rob Herring)
- Added additionalProperties (Rob Herring)
- Split dsi file into two, one for dsi controller
  and another one for dsi phy per target (Rob Herring)
- Corrected description for pinctrl-names (Rob Herring)
- Corrected the examples used in yaml file (Rob Herring)
- Delete dsi.txt and dpu.txt (Rob Herring)

Changes in v4:
- Move schema up by one level (Rob Herring)
- Add patternProperties for mdp node (Rob Herring)
- Corrected description of some properties (Rob Herring)

Changes in v5:
- Correct the indentation (Rob Herring)
- Remove unnecessary description from properties (Rob Herring)
- Correct the number of interconnect entries (Rob Herring)
- Add interconnect names for sc7180 (Rob Herring)
- Add description for ports (Rob Herring)
- Remove common properties (Rob Herring)
- Add unevalutatedProperties (Rob Herring)
- Reference existing dsi controller yaml in the common
  dsi controller file (Rob Herring)
- Correct the description of clock names to include only the
  clocks that are required (Rob Herring)
- Remove properties which are already covered under the common
  binding (Rob Herring)
- Add dsi phy supply nodes which are required for sc7180 and
  sdm845 targets (Rob Herring)
- Add type ref for syscon-sfpb (Rob Herring)

Changes in v6:
- Fixed errors during dt_binding_check (Rob Herring)
- Add maxItems for phys and phys-names (Rob Herring)
- Use unevaluatedProperties wherever required (Rob Herring)
- Removed interrupt controller from required properties for
  dsi controller (Rob Herring)
- Add constraints for dsi-phy reg-names based on the compatible
  phy version (Rob Herring)
- Add constraints for dsi-phy supply nodes based on the
  compatible phy version (Rob Herring)

Changes in v7:
- Add default value for qcom,mdss-mdp-transfer-time-us (Rob 
Herring)

- Modify the schema for data-lanes (Rob Herring)
- Split the phy schema into separate schemas based on
  the phy version (Rob Herring)

Changes in v8:
- Resolve merge conflicts with latest dsi.txt file
- Include dp yaml change also in the same series


I'm done reviewing this because I'm tired of repeating myself and 
you're

just throwing crap at the wall and seeing what sticks. Get someone else
working on QCom stuff to review because I'm done until someone I know
and trust reviews it.


---
 .../bindings/display/msm/dpu-sc7180.yaml   | 236 
+++
 .../bindings/display/msm/dpu-sdm845.yaml   | 216 
++

 .../devicetree/bindings/display/msm/dpu.txt| 141 
 .../display/msm/dsi-common-controller.yaml | 249 
+

 .../display/msm/dsi-controller-sc7180.yaml | 120 ++
 .../display/msm/dsi-controller-sdm845.yaml | 120 ++


Once again, what's the difference between dsi-controller-sc7180.yaml 
and

dsi-controller-sdm845.yaml? I don't see one. If there's not a
difference, why do we have msm/dsi-common-controller.yaml? If there is 
a

difference dsi-controller-sc7180.yaml and dsi-controller-sdm845.yaml
should *only* have what's different because
msm/dsi-common-controller.yaml should have everything that is the same.


Rob, The dsi yaml files were split into dsi controller and dsi phy based 
on your comments on patch v2.
As per the comments, I added one common yaml file for controller with 
all the mandatory and optional properties along with their constraints 
and only the required properties for each target is mentioned in the 
target specific dsi-controller yaml file.


Thanks,
Krishna


 .../bindings/display/msm/dsi-phy-10nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-14nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-20nm.yaml |  66 ++
 .../bindings/display/msm/dsi-phy-28nm.yaml |  62 +
 .../bindings/display/msm/dsi-phy-sc7180.yaml   |  80 +++
 .../bindings/display/msm/dsi-phy-sdm845.yaml   |  82 +++
 .../devicetree/bindings/display/msm

RE: [PATCH] [v2] blk-mq: use BLK_MQ_NO_TAG for no tag

[Tianxianting]

Hi Ming Lei
Thanks for your quick comment.
As the function request_to_qc_t() in 'include/linux/blk-mq.h ' used the magic 
'-1',
Seems it is hard to replace it with BLK_MQ_NO_TAG :(

-Original Message-
From: Ming Lei [mailto:ming@redhat.com] 
Sent: Wednesday, August 26, 2020 12:29 PM
To: tianxianting (RD) 
Cc: ax...@kernel.dk; linux-bl...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] blk-mq: use BLK_MQ_NO_TAG for no tag

On Wed, Aug 26, 2020 at 10:06:51AM +0800, Xianting Tian wrote:
> Replace various magic -1 constants for tags with BLK_MQ_NO_TAG.
> And move the definition of BLK_MQ_NO_TAG from 'block/blk-mq-tag.h'
> to 'include/linux/blk-mq.h'

All three symbols are supposed for block core internal code only, so looks you 
shouldn't move them to public header.


Thanks,
Ming

[PATCH] drm/hisilicon: Removed the dependency on the mmu

[Tian Tao]

hibmc can only be used in ARM64 architectures, and mmu defaults to y
in arch/arm64/Kconfig, so there is no need to add a dependency on mmu
in hibmc's kconfig.

Signed-off-by: Tian Tao 
---
 drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/Kconfig 
b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
index dfc5aef..43943e9 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/Kconfig
+++ b/drivers/gpu/drm/hisilicon/hibmc/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config DRM_HISI_HIBMC
tristate "DRM Support for Hisilicon Hibmc"
-   depends on DRM && PCI && MMU && ARM64
+   depends on DRM && PCI && ARM64
select DRM_KMS_HELPER
select DRM_VRAM_HELPER
select DRM_TTM
-- 
2.7.4

Re: [PATCH] iommu: Add support to filter non-strict/lazy mode based on device names

[Sai Prakash Ranjan]

Hi,

On 2020-08-26 03:45, Doug Anderson wrote:

Hi,

On Tue, Aug 25, 2020 at 12:01 PM Sai Prakash Ranjan
 wrote:


Hi,

On 2020-08-25 21:40, Doug Anderson wrote:
> Hi,
>
> On Tue, Aug 25, 2020 at 8:43 AM Sai Prakash Ranjan
>  wrote:
>>
>> Currently the non-strict or lazy mode of TLB invalidation can only be
>> set
>> for all or no domains. This works well for development platforms where
>> setting to non-strict/lazy mode is fine for performance reasons but on
>> production devices, we need a more fine grained control to allow only
>> certain peripherals to support this mode where we can be sure that it
>> is
>> safe. So add support to filter non-strict/lazy mode based on the
>> device
>> names that are passed via cmdline parameter "iommu.nonstrict_device".
>>
>> Example:
>> iommu.nonstrict_device="7c4000.sdhci,a60.dwc3,6048000.etr"


Just curious: are device names like this really guaranteed to be
stable across versions?



Good question, AFAIK the device names are based on the DT node address 
and
the node name, for ex:  etr@6048000 and device name - "6048000.etr", now 
I
believe these are pretty stable for a particular SoC or board since 
there
is no reason to change the device node name or the address unless 
something
has gone terribly wrong. I don't know about ACPI systems, but however 
they
are described can be specified in this command line parameter. This is 
an
advantage over the DT property where ACPI systems get left out unless 
someone

goes and adds the same/similar property over there.




> I have an inherent dislike of jamming things like this onto the
> command line.  IMHO the command line is the last resort for specifying
> configuration and generally should be limited to some specialized
> debug options and cases where the person running the kernel needs to
> override a config that was set by the person (or company) compiling
> the kernel.  Specifically, having a long/unwieldy command line makes
> it harder to use for the case when an end user actually wants to use
> it to override something.  It's also just another place to look for
> config.
>

Good thing about command line parameters are that they are optional,
they do
not specify any default behaviour (I mean they are not mandatory to be
set
for the system to be functional), so I would like to view it as an
optional
config. And this command line parameter (nonstrict_device) is strictly
optional
with default being strict already set in the driver.

They can be passed from the bootloader via chosen node for DT 
platforms

or choose
a new *bootconfig* as a way to pass the cmdline but finally it does 
boil

down to
just another config.


Never looked at bootconfig.  Unfortunately it seems to require
initramfs so that pretty much means it's out for my usage.  :(



Yes that won't fit everywhere.




I agree with general boolean or single value command line parameters
being just
more messy which could just be Kconfigs instead but for multiple value
parameters
like these do not fit in Kconfig.

As you might already know, command line also gives an advantage to the
end user
to configure system without building kernel, for this specific command
line its
very useful because the performance bump is quite noticeable when the
iommu.strict
is off. Now for end user who would not be interested in building 
entire

kernel(majority)
and just cares about good speeds or throughput can find this very
beneficial.
I am not talking about one specific OS usecase here but more in 
general

term.

> The other problem is that this doesn't necessarily scale very well.
> While it works OK for embedded cases it doesn't work terribly well for
> distributions.  I know that in an out-of-band thread you indicated
> that it doesn't break anything that's not already broken (AKA this
> doesn't fix the distro case but it doesn't make it worse), it would be
> better to come up with a more universal solution.
>

Is the universal solution here referring to fix all the command line
parameters
in the kernel or this specific command line? Are we going to remove 
any

more
addition to the cmdline ;)


There are very few cases where a kernel command line parameter is the
only way to configure something.  Most of the time it's just there to
override a config.  I wouldn't suggest removing those.  I just don't
want a kernel command line parameter to be the primary way to enable
something.



Agreed that command line parameters are not supposed to be some primary
way of setting things but an optional way to override settings, in this
case to override the strict mode already set by the driver. Then we can
probably agree that this command line is just an optional way provided
to the end user for his convenience? We would still need to find a 
primary
way to set this non-strict mode in drivers via DT passing the 
information

or some other way.




So possible other solution is the *bootconfig* which is again just
another place
to look for a config. So thing is that this universal 

RE: [PATCH 3/3] usb: cdns3: Enable workaround for USB2.0 PHY Rx compliance test PHY lockup

[Peter Chen]

 
> 
> 
> >
> >On 20-08-26 04:04:01, Pawel Laszczak wrote:
> >> >On 20-08-25 15:00:59, Roger Quadros wrote:
> >> >> From: Pawel Laszczak 
> >> >>
> >> >> USB2.0 PHY hangs in Rx Compliance test when the incoming packet
> >> >> amplitude is varied below and above the Squelch Level of Receiver
> >> >> during the active packet multiple times.
> >> >>
> >> >> Version 1 of the controller allows PHY to be reset when RX fail
> >> >> condition is detected to work around the above issue. This feature
> >> >> is disabled by default and needs to be enabled using a bit from
> >> >> the newly added PHYRST_CFG register. This patch enables the workaround.
> >> >>
> >> >> As there is no way to distinguish between the controller version
> >> >> before the device controller is started we need to rely on a DT
> >> >> property to decide when to apply the workaround.
> >> >
> >> >Pawel, it could know the controller version at cdns3_gadget_start,
> >> >but the controller starts when it tries to bind gadget driver, at
> >> >that time, it has already known the controller version.
> >> >
> >> >For me, the device controller starts is using USB_CONF.DEVEN (Device
> >> >Enable) through usb_gadget_connect, I am not sure if it is the same
> >> >with yours.
> >> >
> >>
> >> Yes in device mode driver knows controller version but this
> >> workaround Must be enabled also in host mode. In host mode the
> >> controller doesn't have access to device registers. The controller
> >> version is placed in device register.
> >>
> >
> >You may suggest your design team adding CHIP_VER register at global
> >register region, it will easy the software engineer life.
> >
> >From what I read, this register is only enabling USB2 PHY reset
> >software control, it needs for all chips with rev 0x0002450D, and the
> >place you current change is only for 0x0002450D, right?
> 
> Even I could say that this workaround should be enabled only for Specific USB2
> PHY  (only 0x0002450D)
> 
> This bit should not have any impact for Cadence PHY but it can has Impact for 
> third
> party PHYs.
> 

So, it is related to specific PHY, but enable this specific PHY reset bit is at 
controller region, why don't
put this enable bit at PHY region?

So, you use controller's device property to know this specific PHY, can 
controller know this specific
PHY dynamically?

Peter

> Pawel
> 
> >
> >Peter
> >
> >> Pawel
> >>
> >> >Peter
> >> >
> >> >
> >> >>
> >> >> Signed-off-by: Pawel Laszczak 
> >> >> Signed-off-by: Roger Quadros 
> >> >> ---
> >> >>  drivers/usb/cdns3/core.c |  2 ++
> >> >>  drivers/usb/cdns3/core.h |  1 +
> >> >>  drivers/usb/cdns3/drd.c  | 12 
> >> >> drivers/usb/cdns3/drd.h  |  5 -
> >> >>  4 files changed, 19 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/usb/cdns3/core.c b/drivers/usb/cdns3/core.c
> >> >> index 5c1586ec7824..34b36487682b 100644
> >> >> --- a/drivers/usb/cdns3/core.c
> >> >> +++ b/drivers/usb/cdns3/core.c
> >> >> @@ -443,6 +443,8 @@ static int cdns3_probe(struct platform_device *pdev)
> >> >> return -ENXIO;
> >> >> }
> >> >>
> >> >> +   cdns->phyrst_a_enable = device_property_read_bool(dev,
> >> >> +"cdns,phyrst-a-enable");
> >> >> +
> >> >> cdns->otg_res = *res;
> >> >>
> >> >> mutex_init(&cdns->mutex);
> >> >> diff --git a/drivers/usb/cdns3/core.h b/drivers/usb/cdns3/core.h
> >> >> index 1ad1f1fe61e9..24cf0f1b5726 100644
> >> >> --- a/drivers/usb/cdns3/core.h
> >> >> +++ b/drivers/usb/cdns3/core.h
> >> >> @@ -76,6 +76,7 @@ struct cdns3 {
> >> >>  #define CDNS3_CONTROLLER_V00
> >> >>  #define CDNS3_CONTROLLER_V11
> >> >> u32 version;
> >> >> +   boolphyrst_a_enable;
> >> >>
> >> >> int otg_irq;
> >> >> int dev_irq;
> >> >> diff --git a/drivers/usb/cdns3/drd.c b/drivers/usb/cdns3/drd.c
> >> >> index 6234bcd6158a..b74803e9703d 100644
> >> >> --- a/drivers/usb/cdns3/drd.c
> >> >> +++ b/drivers/usb/cdns3/drd.c
> >> >> @@ -42,6 +42,18 @@ int cdns3_set_mode(struct cdns3 *cdns, enum
> usb_dr_mode mode)
> >> >> reg = readl(&cdns->otg_v1_regs->override);
> >> >> reg |= OVERRIDE_IDPULLUP;
> >> >> writel(reg, &cdns->otg_v1_regs->override);
> >> >> +
> >> >> +   /*
> >> >> +* Enable work around feature built into the
> >> >> +* controller to address issue with RX 
> >> >> Sensitivity
> >> >> +* est (EL_17) for USB2 PHY. The issue only 
> >> >> occures
> >> >> +* for 0x0002450D controller version.
> >> >> +*/
> >> >> +   if (cdns->phyrst_a_enable) {
> >> >> +   reg = 
> >> >> readl(&cdns->otg_v1_regs->phyrst_cfg);
> >> >> +   reg |= PHYRST_CFG_PHYRST_A

Re: [PATCH 4.19 00/71] 4.19.142-rc1 review

[Pavel Machek]

Hi!

> This is the start of the stable review cycle for the 4.19.142 release.
> There are 71 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed, 26 Aug 2020 08:23:34 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.142-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.

Uh. I believe this was tested successfully by CIP probject:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/181017473

Yes, there are two "fails" but there seem to be caused by DNS
resolution problems (i.e. test infrastructure problem, not kernel problem).

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [ANNOUNCE] v5.9-rc2-rt1

[Daniel Wagner]

Hi Sebastian,

On Mon, Aug 24, 2020 at 05:46:05PM +0200, Sebastian Andrzej Siewior wrote:
> I'm pleased to announce the v5.9-rc2-rt1 patch set.

I gave it a quick run on my test system. Can't boot the system at this
point. Didn't look closer at it, maybe it's something obvious...

 stack segment:  [#1] PREEMPT_RT SMP PTI
 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-rc2-rt1 #1
 Hardware name: wortmann G31M-ES2L/G31M-S2L, BIOS F10 09/29/2009
 RIP: 0010:intel_pipe_update_start+0x139/0x5f0
 Code: ed 7c a1 ff 48 8d 83 b8 05 00 00 48 89 c5 48 89 04 24 e8 ea 75 51 00 89 
c0 48 03 2c c5 a0 26 0e a0 65 48 8b 04 25 80 6c 01 00 <48> 39 45 30 0f 84 4a 01 
00 00 48 89 ef e8 35 e2 51 00 8b 35 b7 42
 RSP: :bc3d800179c8 EFLAGS: 00010287
 
 RAX: 9c91ab22 RBX: 9c91aaac6800 RCX: 
 RDX: 0001 RSI: a0015367 RDI: a003f1de
 RBP: 3923566c6db8 R08:  R09: 0001
 R10: 9c91ab292b90 R11: 00ba R12: 01e8
 R13: 9c91a9e9cc30 R14: 01e4 R15: 01e7
 FS:  () GS:9c91abc0() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2:  CR3: ac41a000 CR4: 000406f0
 Call Trace:
  ? preempt_count_add+0x68/0xa0
  ? _raw_spin_lock+0x13/0x30
  ? wait_woken+0x90/0x90
  intel_update_crtc+0xa7/0x360
  ? wait_woken+0x90/0x90
  intel_commit_modeset_enables+0x5e/0x80
  intel_atomic_commit_tail+0x311/0x1210
  ? __queue_work+0x372/0x540
  ? migrate_enable+0x11b/0x430
  intel_atomic_commit+0x357/0x3e0
  intel_modeset_init+0x84d/0x1e50
  i915_driver_probe+0x95d/0xe00
  i915_pci_probe+0x44/0x120
  local_pci_probe+0x26/0x50
  pci_device_probe+0xd5/0x160
  really_probe+0xdb/0x2e0
  device_driver_attach+0x53/0x60
  __driver_attach+0x4c/0xc0
  ? device_driver_attach+0x60/0x60
  bus_for_each_dev+0x7b/0xc0
  bus_add_driver+0x17a/0x1c0
  driver_register+0x6c/0xc0
  ? mipi_dsi_bus_init+0x11/0x11
  i915_init+0x58/0x6b
  do_one_initcall+0x46/0x274
  kernel_init_freeable+0x199/0x1dc
  ? rest_init+0xba/0xba
  kernel_init+0xa/0x106
  ret_from_fork+0x22/0x30
 Modules linked in:
 
 Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
 Kernel Offset: 0x1de0 from 0x8100 (relocation range: 
0x8000-0xbfff)
 ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b ]---

Thanks,
Daniel

Re: [PATCH 4.4 00/33] 4.4.234-rc1 review

[Pavel Machek]

Hi!

> Responses should be made by Wed, 26 Aug 2020 08:23:34 +.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.234-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>

I believe this was tested successfully with CIP project:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/181017460

Yes, they are failures, but they are DNS resolution problems during
testing.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] mm: memcg: Fix memcg reclaim soft lockup

[Michal Hocko]

On Wed 26-08-20 15:27:02, Xunlei Pang wrote:
> We've met softlockup with "CONFIG_PREEMPT_NONE=y", when
> the target memcg doesn't have any reclaimable memory.

Do you have any scenario when this happens or is this some sort of a
test case?

> It can be easily reproduced as below:
>  watchdog: BUG: soft lockup - CPU#0 stuck for 111s![memcg_test:2204]
>  CPU: 0 PID: 2204 Comm: memcg_test Not tainted 5.9.0-rc2+ #12
>  Call Trace:
>   shrink_lruvec+0x49f/0x640
>   shrink_node+0x2a6/0x6f0
>   do_try_to_free_pages+0xe9/0x3e0
>   try_to_free_mem_cgroup_pages+0xef/0x1f0
>   try_charge+0x2c1/0x750
>   mem_cgroup_charge+0xd7/0x240
>   __add_to_page_cache_locked+0x2fd/0x370
>   add_to_page_cache_lru+0x4a/0xc0
>   pagecache_get_page+0x10b/0x2f0
>   filemap_fault+0x661/0xad0
>   ext4_filemap_fault+0x2c/0x40
>   __do_fault+0x4d/0xf9
>   handle_mm_fault+0x1080/0x1790
> 
> It only happens on our 1-vcpu instances, because there's no chance
> for oom reaper to run to reclaim the to-be-killed process.
> 
> Add cond_resched() in such cases at the beginning of shrink_lruvec()
> to give up the cpu to others.

I do agree that we need a cond_resched but I cannot say I would like
this patch. The primary reason is that it doesn't catch all cases when
the memcg is not reclaimable. For example it wouldn't reschedule if the
memcg is protected by low/min. What do you think about this instead?

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 99e1796eb833..bbdc38b58cc5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2617,6 +2617,8 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct 
scan_control *sc)
 
mem_cgroup_calculate_protection(target_memcg, memcg);
 
+   cond_resched();
+
if (mem_cgroup_below_min(memcg)) {
/*
 * Hard protection.

This should catch both cases. I even have a vague recollection that
somebody has proposed something in that direction but I cannot remember
what has happened with that patch.
-- 
Michal Hocko
SUSE Labs

Re: [ANNOUNCE] v5.9-rc2-rt1

[Sebastian Andrzej Siewior]

On 2020-08-26 10:08:02 [+0200], Daniel Wagner wrote:
> Hi Sebastian,
Hi,

> On Mon, Aug 24, 2020 at 05:46:05PM +0200, Sebastian Andrzej Siewior wrote:
> > I'm pleased to announce the v5.9-rc2-rt1 patch set.
> 
> I gave it a quick run on my test system. Can't boot the system at this
> point. Didn't look closer at it, maybe it's something obvious...

Carsten reported it the other day, but didn't Cc: the list. I've sent
him this to test:

diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 24baa5f2047bb..cc435d0a51215 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -118,8 +118,6 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
"PSR idle timed out 0x%x, atomic update may fail\n",
psr_status);
 
-   local_lock_irq(&crtc->pipe_update_lock);
-
crtc->debug.min_vbl = min;
crtc->debug.max_vbl = max;
trace_intel_pipe_update_start(crtc);
@@ -143,11 +141,7 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
break;
}
 
-   local_unlock_irq(&crtc->pipe_update_lock);
-
timeout = schedule_timeout(timeout);
-
-   local_lock_irq(&crtc->pipe_update_lock);
}
 
finish_wait(wq, &wait);
@@ -180,7 +174,6 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
return;
 
 irq_disable:
-   local_lock_irq(&crtc->pipe_update_lock);
 }
 
 /**
@@ -218,8 +211,6 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
new_crtc_state->uapi.event = NULL;
}
 
-   local_unlock_irq(&crtc->pipe_update_lock);
-
if (intel_vgpu_active(dev_priv))
return;
 

He complained about a stale label and so. 
The RT patch replaced a local-irq-disable with a local-lock which broke.
I intend to get rid of this local-irq-disable on RT, the local-lock is
just duct-tape to make it look the same. If this works for everyone then
I will think of something…

> Thanks,
> Daniel

Sebastian

Re: [PATCH] coccinelle: api: update kzfree script to kfree_sensitive

[Denis Efremov]

Ping?

On 8/11/20 10:49 AM, Denis Efremov wrote:
> Commit 453431a54934 ("mm, treewide: rename kzfree() to kfree_sensitive()")
> renames kzfree to kfree_sensitive and uses memzero_explicit(...) instead of
> memset(..., 0, ...) internally. Update cocci script to reflect these
> changes.
> 
> Signed-off-by: Denis Efremov 
> ---
> Julia, I think you can squash this commit with original script, or I can
> resend the whole script since it's not merged to the mainline.
> 
>  .../{kzfree.cocci => kfree_sensitive.cocci}   | 29 +--
>  1 file changed, 13 insertions(+), 16 deletions(-)
>  rename scripts/coccinelle/api/{kzfree.cocci => kfree_sensitive.cocci} (70%)
> 
> diff --git a/scripts/coccinelle/api/kzfree.cocci 
> b/scripts/coccinelle/api/kfree_sensitive.cocci
> similarity index 70%
> rename from scripts/coccinelle/api/kzfree.cocci
> rename to scripts/coccinelle/api/kfree_sensitive.cocci
> index 33625bd7cec9..e4a066a0b77d 100644
> --- a/scripts/coccinelle/api/kzfree.cocci
> +++ b/scripts/coccinelle/api/kfree_sensitive.cocci
> @@ -1,13 +1,13 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  ///
> -/// Use kzfree, kvfree_sensitive rather than memset or
> -/// memzero_explicit followed by kfree
> +/// Use kfree_sensitive, kvfree_sensitive rather than memset or
> +/// memzero_explicit followed by kfree.
>  ///
>  // Confidence: High
>  // Copyright: (C) 2020 Denis Efremov ISPRAS
>  // Options: --no-includes --include-headers
>  //
> -// Keywords: kzfree, kvfree_sensitive
> +// Keywords: kfree_sensitive, kvfree_sensitive
>  //
>  
>  virtual context
> @@ -18,7 +18,8 @@ virtual report
>  @initialize:python@
>  @@
>  # kmalloc_oob_in_memset uses memset to explicitly trigger out-of-bounds 
> access
> -filter = frozenset(['kmalloc_oob_in_memset', 'kzfree', 'kvfree_sensitive'])
> +filter = frozenset(['kmalloc_oob_in_memset',
> + 'kfree_sensitive', 'kvfree_sensitive'])
>  
>  def relevant(p):
>  return not (filter & {el.current_element for el in p})
> @@ -56,17 +57,13 @@ type T;
>  - memzero_explicit@m((T)E, size);
>... when != E
>when strict
> -// TODO: uncomment when kfree_sensitive will be merged.
> -// Only this case is commented out because developers
> -// may not like patches like this since kzfree uses memset
> -// internally (not memzero_explicit).
> -//(
> -//- kfree(E)@p;
> -//+ kfree_sensitive(E);
> -//|
> +(
> +- kfree(E)@p;
> ++ kfree_sensitive(E);
> +|
>  - \(vfree\|kvfree\)(E)@p;
>  + kvfree_sensitive(E, size);
> -//)
> +)
>  
>  @rp_memset depends on patch@
>  expression E, size;
> @@ -80,7 +77,7 @@ type T;
>when strict
>  (
>  - kfree(E)@p;
> -+ kzfree(E);
> ++ kfree_sensitive(E);
>  |
>  - \(vfree\|kvfree\)(E)@p;
>  + kvfree_sensitive(E, size);
> @@ -91,11 +88,11 @@ p << r.p;
>  @@
>  
>  coccilib.report.print_report(p[0],
> -  "WARNING: opportunity for kzfree/kvfree_sensitive")
> +  "WARNING: opportunity for kfree_sensitive/kvfree_sensitive")
>  
>  @script:python depends on org@
>  p << r.p;
>  @@
>  
>  coccilib.org.print_todo(p[0],
> -  "WARNING: opportunity for kzfree/kvfree_sensitive")
> +  "WARNING: opportunity for kfree_sensitive/kvfree_sensitive")
> 

[PATCH v2 5/5] drm/bridge: ps8640: Rework power state handling

[Enric Balletbo i Serra]

The get_edid() callback can be triggered anytime by an ioctl, i.e

  drm_mode_getconnector (ioctl)
-> drm_helper_probe_single_connector_modes
   -> drm_bridge_connector_get_modes
  -> ps8640_bridge_get_edid

Actually if the bridge pre_enable() function was not called before
get_edid(), the driver will not be able to get the EDID properly and
display will not work until a second get_edid() call is issued and if
pre_enable() is called before. The side effect of this, for example, is
that you see anything when `Frecon` starts, neither the splash screen,
until the graphical session manager starts.

To fix this we need to make sure that all we need is enabled before
reading the EDID. This means the following:

1. If get_edid() is called before having the device powered we need to
   power on the device. In such case, the driver will power off again the
   device.

2. If get_edid() is called after having the device powered, all should
   just work. We added a powered flag in order to avoid recurrent calls
   to ps8640_bridge_poweron() and unneeded delays.

3. This seems to be specific for this device, but we need to make sure
   the panel is powered on before do a power on cycle on this device.
   Otherwise the device fails to retrieve the EDID.

Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

 drivers/gpu/drm/bridge/parade-ps8640.c | 64 +++---
 1 file changed, 58 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 9f7b7a9c53c5..c5d76e209bda 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -65,6 +65,7 @@ struct ps8640 {
struct regulator_bulk_data supplies[2];
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_powerdown;
+   bool powered;
 };
 
 static inline struct ps8640 *bridge_to_ps8640(struct drm_bridge *e)
@@ -91,13 +92,15 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
return 0;
 }
 
-static void ps8640_pre_enable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweron(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
struct i2c_client *client = ps_bridge->page[PAGE2_TOP_CNTL];
unsigned long timeout;
int ret, status;
 
+   if (ps_bridge->powered)
+   return;
+
ret = regulator_bulk_enable(ARRAY_SIZE(ps_bridge->supplies),
ps_bridge->supplies);
if (ret < 0) {
@@ -164,6 +167,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
goto err_regulators_disable;
}
 
+   ps_bridge->powered = true;
+
return;
 
 err_regulators_disable:
@@ -171,12 +176,12 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
   ps_bridge->supplies);
 }
 
-static void ps8640_post_disable(struct drm_bridge *bridge)
+static void ps8640_bridge_poweroff(struct ps8640 *ps_bridge)
 {
-   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (!ps_bridge->powered)
+   return;
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
@@ -184,6 +189,28 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
 ps_bridge->supplies);
if (ret < 0)
DRM_ERROR("cannot disable regulators %d\n", ret);
+
+   ps_bridge->powered = false;
+}
+
+static void ps8640_pre_enable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   int ret;
+
+   ps8640_bridge_poweron(ps_bridge);
+
+   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   if (ret < 0)
+   ps8640_bridge_poweroff(ps_bridge);
+}
+
+static void ps8640_post_disable(struct drm_bridge *bridge)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
+   ps8640_bridge_poweroff(ps_bridge);
 }
 
 static int ps8640_bridge_attach(struct drm_bridge *bridge,
@@ -249,9 +276,34 @@ static struct edid *ps8640_bridge_get_edid(struct 
drm_bridge *bridge,
   struct drm_connector *connector)
 {
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+   bool poweroff = !ps_bridge->powered;
+   struct edid *edid;
+
+   /*
+* When we end calling get_edid() triggered by an ioctl, i.e
+*
+*   drm_mode_getconnector (ioctl)
+* -> drm_helper_probe_single_connector_modes
+*-> drm_bridge_connector_get_modes
+*   -> ps8640_bridge_get_edid
+*
+* We need to make sure that what we need is enabled before reading
+* EDID, f

[PATCH v2 1/5] drm/bridge_connector: Set default status connected for eDP connectors

[Enric Balletbo i Serra]

In an eDP application, HPD is not required and on most bridge chips
useless. If HPD is not used, we need to set initial status as connected,
otherwise the connector created by the drm_bridge_connector API remains
in an unknown state.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`

 drivers/gpu/drm/drm_bridge_connector.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_bridge_connector.c 
b/drivers/gpu/drm/drm_bridge_connector.c
index c6994fe673f3..a58cbde59c34 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector 
*connector, bool force)
case DRM_MODE_CONNECTOR_DPI:
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_eDP:
status = connector_status_connected;
break;
default:
-- 
2.28.0

[PATCH v2 0/5] drm/bridge: ps8640: Make sure all needed is powered to get the EDID

[Enric Balletbo i Serra]

The first patch was initially part of the series [1] but for some reason
was not picked when the series were merged, so I included in this series
because it is needed to make the others to work properly.

The same happened for the second patch, was part of series [1] but not
merged.

The third patch and next are part of the original series and are to rework
the power handling to get the EDID. Basically, we need to make sure all the
needed is powered to be able to get the EDID. Before, we saw that getting
the EDID failed as explained in the third patch.

[1] https://lkml.org/lkml/2020/6/15/1208

Changes in v2:
- Included the patch `drm/bridge_connector: Set default status connected for 
eDP connectors`
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`
- Use drm_bridge_chain_pre_enable/post_disable() helpers (Sam Ravnborg)

Enric Balletbo i Serra (5):
  drm/bridge_connector: Set default status connected for eDP connectors
  drm/bridge: ps8640: Get the EDID from eDP control
  drm/bridge: ps8640: Return an error for incorrect attach flags
  drm/bridge: ps8640: Print an error if VDO control fails
  drm/bridge: ps8640: Rework power state handling

 drivers/gpu/drm/bridge/parade-ps8640.c | 89 ++
 drivers/gpu/drm/drm_bridge_connector.c |  1 +
 2 files changed, 79 insertions(+), 11 deletions(-)

-- 
2.28.0

[PATCH v2 2/5] drm/bridge: ps8640: Get the EDID from eDP control

[Enric Balletbo i Serra]

The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.

Reviewed-by: Laurent Pinchart 
Acked-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Included the patch `drm/bridge: ps8640: Get the EDID from eDP control`

 drivers/gpu/drm/bridge/parade-ps8640.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
 }
 
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+  struct drm_connector *connector)
+{
+   struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+   return drm_get_edid(connector,
+   ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
 static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+   .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
 };
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
 
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+   ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+   ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
 
ps_bridge->page[PAGE0_DP_CNTL] = client;
 
-- 
2.28.0

[PATCH v2 3/5] drm/bridge: ps8640: Return an error for incorrect attach flags

[Enric Balletbo i Serra]

Bridge drivers that implement the new model only shall return an error
from their attach() handler when the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag
is not set. So make sure we return an error because only the new
drm_bridge model is supported.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 13755d278db6..ce3e8b2da8c9 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -200,6 +200,10 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
   .channel = 0,
   .node = NULL,
 };
+
+   if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+   return -EINVAL;
+
/* port@0 is ps8640 dsi input port */
in_ep = of_graph_get_endpoint_by_regs(dev->of_node, 0, -1);
if (!in_ep)
-- 
2.28.0

[PATCH v2 4/5] drm/bridge: ps8640: Print an error if VDO control fails

[Enric Balletbo i Serra]

Print an error message inside ps8640_bridge_vdo_control() function when
it fails so we can simplify a bit the callers, they will only need to
check the error code.

Reviewed-by: Sam Ravnborg 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/bridge/parade-ps8640.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
index ce3e8b2da8c9..9f7b7a9c53c5 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -82,8 +82,11 @@ static int ps8640_bridge_vdo_control(struct ps8640 
*ps_bridge,
ret = i2c_smbus_write_i2c_block_data(client, PAGE3_SET_ADD,
 sizeof(vdo_ctrl_buf),
 vdo_ctrl_buf);
-   if (ret < 0)
+   if (ret < 0) {
+   DRM_ERROR("failed to %sable VDO: %d\n",
+ ctrl == ENABLE ? "en" : "dis", ret);
return ret;
+   }
 
return 0;
 }
@@ -150,10 +153,8 @@ static void ps8640_pre_enable(struct drm_bridge *bridge)
}
 
ret = ps8640_bridge_vdo_control(ps_bridge, ENABLE);
-   if (ret) {
-   DRM_ERROR("failed to enable VDO: %d\n", ret);
+   if (ret)
goto err_regulators_disable;
-   }
 
/* Switch access edp panel's edid through i2c */
ret = i2c_smbus_write_byte_data(client, PAGE2_I2C_BYPASS,
@@ -175,9 +176,7 @@ static void ps8640_post_disable(struct drm_bridge *bridge)
struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
int ret;
 
-   ret = ps8640_bridge_vdo_control(ps_bridge, DISABLE);
-   if (ret < 0)
-   DRM_ERROR("failed to disable VDO: %d\n", ret);
+   ps8640_bridge_vdo_control(ps_bridge, DISABLE);
 
gpiod_set_value(ps_bridge->gpio_reset, 1);
gpiod_set_value(ps_bridge->gpio_powerdown, 1);
-- 
2.28.0

Re: [net-next v5 1/6] net: marvell: prestera: Add driver for Prestera family ASIC devices

[Vadym Kochan]

On Tue, Aug 25, 2020 at 05:20:03PM -0700, David Miller wrote:
> From: Vadym Kochan 
> Date: Tue, 25 Aug 2020 15:20:08 +0300
> 
> > +int prestera_dsa_parse(struct prestera_dsa *dsa, const u8 *dsa_buf)
> > +{
> > +   __be32 *dsa_words = (__be32 *)dsa_buf;
> > +   enum prestera_dsa_cmd cmd;
> > +   u32 words[4] = { 0 };
> > +   u32 field;
> > +
> > +   words[0] = ntohl(dsa_words[0]);
> > +   words[1] = ntohl(dsa_words[1]);
> > +   words[2] = ntohl(dsa_words[2]);
> > +   words[3] = ntohl(dsa_words[3]);
> 
> All 4 elements of words[] are explicitly and unconditionally set to something,
> so you don't need the "= { 0 }" initializer.

Right, will fix it.

> 
> > +   INIT_LIST_HEAD(&sw->port_list);
> 
> What locking protects this list?
> 

Initially there was (in RFC patch set), not locking, but _rcu list API
used, because the port list is modified only by 1 writer when creating
the port or deleting it on switch uninit (the really theoretical case
which might happen is that event might be received at that time which
causes to loop over this list to find the port), as I understand
correctly list_add_rcu is safe to use with no additional locking if there is 1
writer and many readers ? So can I use back this approach ?

> > +   new_skb = alloc_skb(len, GFP_ATOMIC | GFP_DMA);
> > +   if (!new_skb)
> > +   goto err_alloc_skb;
> 
> This seems very costly to do copies on every packet.  There should be
> something in the dma_*() API that would allow you to avoid this.

There is a limitation on the DMA range. Current device can't handle
whole ZONE_DMA range, so there is a "backup" mechanism which copies the
entire packet if the mapping was failed or if the packet's mapped
address is out of this range, this is done on both rx and tx directions.

> 
> And since you just need the buffer to DMA map it into the device,
> allocating an entire SKB object is overkill.  You can instead just
> allocate a ring of TX bounce buffers once, and then you just copy
> each packet there.  No allocations per packet.

Yes, this makes sense, thanks.

Re: [PATCH 01/19] char_dev: replace cdev_map with an xarray

[Greg Kroah-Hartman]

On Wed, Aug 26, 2020 at 08:24:28AM +0200, Christoph Hellwig wrote:
> None of the complicated overlapping regions bits of the kobj_map are
> required for the character device lookup, so just a trivial xarray
> instead.
> 
> Signed-off-by: Christoph Hellwig 

Really?  This is ok to use and just as fast?  If so, wonderful, it would
be great to clean up kobj_map users.

But I don't think you got all of the needed bits here:

> ---
>  fs/char_dev.c | 94 +--
>  fs/dcache.c   |  1 -
>  fs/internal.h |  5 ---
>  3 files changed, 46 insertions(+), 54 deletions(-)
> 
> diff --git a/fs/char_dev.c b/fs/char_dev.c
> index ba0ded7842a779..6c4d6c4938f14b 100644
> --- a/fs/char_dev.c
> +++ b/fs/char_dev.c
> @@ -17,7 +17,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -25,8 +24,7 @@
>  
>  #include "internal.h"
>  
> -static struct kobj_map *cdev_map;
> -
> +static DEFINE_XARRAY(cdev_map);
>  static DEFINE_MUTEX(chrdevs_lock);
>  
>  #define CHRDEV_MAJOR_HASH_SIZE 255
> @@ -367,6 +365,29 @@ void cdev_put(struct cdev *p)
>   }
>  }
>  
> +static struct cdev *cdev_lookup(dev_t dev)
> +{
> + struct cdev *cdev;
> +
> +retry:
> + mutex_lock(&chrdevs_lock);
> + cdev = xa_load(&cdev_map, dev);
> + if (!cdev) {
> + mutex_unlock(&chrdevs_lock);
> +
> + if (request_module("char-major-%d-%d",
> +MAJOR(dev), MINOR(dev)) > 0)
> + /* Make old-style 2.4 aliases work */
> + request_module("char-major-%d", MAJOR(dev));
> + goto retry;
> + }
> +
> + if (!cdev_get(cdev))
> + cdev = NULL;
> + mutex_unlock(&chrdevs_lock);
> + return cdev;
> +}
> +
>  /*
>   * Called every time a character special file is opened
>   */
> @@ -380,13 +401,10 @@ static int chrdev_open(struct inode *inode, struct file 
> *filp)
>   spin_lock(&cdev_lock);
>   p = inode->i_cdev;
>   if (!p) {
> - struct kobject *kobj;
> - int idx;
>   spin_unlock(&cdev_lock);
> - kobj = kobj_lookup(cdev_map, inode->i_rdev, &idx);
> - if (!kobj)
> + new = cdev_lookup(inode->i_rdev);
> + if (!new)
>   return -ENXIO;
> - new = container_of(kobj, struct cdev, kobj);
>   spin_lock(&cdev_lock);
>   /* Check i_cdev again in case somebody beat us to it while
>  we dropped the lock. */
> @@ -454,18 +472,6 @@ const struct file_operations def_chr_fops = {
>   .llseek = noop_llseek,
>  };
>  
> -static struct kobject *exact_match(dev_t dev, int *part, void *data)
> -{
> - struct cdev *p = data;
> - return &p->kobj;
> -}
> -
> -static int exact_lock(dev_t dev, void *data)
> -{
> - struct cdev *p = data;
> - return cdev_get(p) ? 0 : -1;
> -}
> -
>  /**
>   * cdev_add() - add a char device to the system
>   * @p: the cdev structure for the device
> @@ -478,7 +484,7 @@ static int exact_lock(dev_t dev, void *data)
>   */
>  int cdev_add(struct cdev *p, dev_t dev, unsigned count)
>  {
> - int error;
> + int error, i;
>  
>   p->dev = dev;
>   p->count = count;
> @@ -486,14 +492,22 @@ int cdev_add(struct cdev *p, dev_t dev, unsigned count)
>   if (WARN_ON(dev == WHITEOUT_DEV))
>   return -EBUSY;
>  
> - error = kobj_map(cdev_map, dev, count, NULL,
> -  exact_match, exact_lock, p);
> - if (error)
> - return error;
> + mutex_lock(&chrdevs_lock);
> + for (i = 0; i < count; i++) {
> + error = xa_insert(&cdev_map, dev + i, p, GFP_KERNEL);
> + if (error)
> + goto out_unwind;
> + }
> + mutex_unlock(&chrdevs_lock);
>  
>   kobject_get(p->kobj.parent);

Can't you drop this kobject_get() too?

And also the "struct kobj" in struct cdev can be gone as well, as the
kobj_map was the only "real" user of this structure.  I know some
drivers liked to touch that field as well, but it never actually did
anything for them, so it was pointless, but it will take some 'make
allmodconfig' builds to flush them out.

thanks,

greg k-h

Re: [PATCH 02/19] block: merge drivers/base/map.c into block/genhd.c

[Greg Kroah-Hartman]

On Wed, Aug 26, 2020 at 08:24:29AM +0200, Christoph Hellwig wrote:
> Now that there is just a single user of the kobj_map functionality left,
> merge it into the user to prepare for additional simplications.
> 
> Signed-off-by: Christoph Hellwig 

YES!!!

Reviewed-by: Greg Kroah-Hartman 

RE: [PATCH] spi: spi-fsl-dspi: Add ACPI support

[Qiang Zhao]

On Mon, Aug 24, 2020 at 19:25, Mark Brown  wrote:
> -Original Message-
> From: Mark Brown 
> Sent: 2020年8月24日 19:25
> To: Vladimir Oltean 
> Cc: kuldip dwivedi ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Qiang Zhao
> ; Pankaj Bansal ; Varun Sethi
> ; Tanveer Alam 
> Subject: Re: [PATCH] spi: spi-fsl-dspi: Add ACPI support
> 
> On Sat, Aug 22, 2020 at 06:21:18PM +0300, Vladimir Oltean wrote:
> > On Sat, Aug 22, 2020 at 07:37:25PM +0530, Kuldip Dwivedi wrote:
> 
> > > > The whole point with the device property API is that it works with
> > > > both DT and ACPI without needing separate parsing, though in this
> > > > case I'm wondering why we'd need to specify this in an ACPI system
> > > > at all?
> 
> > > Understood. Will take care in v2 PATCH
> 
> > IMO there is zero reason for the existence of the "spi-num-chipselects"
> > property even for DT. We should deprecate it (start ignoring it in
> > existing device tree deployments) and populate struct
> > fsl_dspi_devtype_data with that info based on SoC compatible string.
> 
> Yes, it's a legacy from bad board file conversions and shouldn't be used at 
> all.

I saw a lot of driver assign spi_controller -> num_chipselect directly, should 
we do like that?

BR
Qiang Zhao

Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)

[Masami Hiramatsu]

On Wed, 26 Aug 2020 07:07:09 +
"eddy...@trendmicro.com"  wrote:

> 
> > -Original Message-
> > From: pet...@infradead.org 
> > Sent: Tuesday, August 25, 2020 8:09 PM
> > To: Masami Hiramatsu 
> > Cc: Eddy Wu (RD-TW) ; linux-kernel@vger.kernel.org; 
> > x...@kernel.org; David S. Miller
> > 
> > Subject: Re: x86/kprobes: kretprobe fails to triggered if kprobe at 
> > function entry is not optimized (trigger by int3 breakpoint)
> >
> > Surely we can do a lockless list for this. We have llist_add() and
> > llist_del_first() to make a lockless LIFO/stack.
> >
> 
> llist operations require atomic cmpxchg, for some arch doesn't have 
> CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG, in_nmi() check might still needed.
> (HAVE_KRETPROBES && !CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG): arc, arm, csky, mips

Good catch. In those cases, we can add in_nmi() check at arch dependent code.

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH RESEND] fs: Move @f_count to different cacheline with @f_mode

[Aleksa Sarai]

On 2020-08-26, Shaokun Zhang  wrote:
> 在 2020/8/22 0:02, Will Deacon 写道:
> >   - This thing is tagged with __randomize_layout, so it doesn't help anybody
> > using that crazy plugin
> 
> This patch isolated the @f_count with @f_mode absolutely and we don't care the
> base address of the structure, or I may miss something what you said.

__randomize_layout randomises the order of fields in a structure on each
kernel rebuild (to make attacks against sensitive kernel structures
theoretically harder because the offset of a field is per-build). It is
separate to ASLR or other base-related randomisation. However it depends
on having CONFIG_GCC_PLUGIN_RANDSTRUCT=y and I believe (at least for
distribution kernels) this isn't a widely-used configuration.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge

[Enric Balletbo i Serra]

Hi Bilal,

On 24/8/20 21:01, Bilal Wasim wrote:
> Hi Chun-Kuan, Enric,
> 
> Is there any plan to merge the following commits in this series to the 
> mainline?
> 
>   drm/bridge: ps8640: Get the EDID from eDP control
>   drm/bridge_connector: Set default status connected for eDP connectors
> 

Just sent a new series including this patches:
https://lore.kernel.org/patchwork/project/lkml/list/?series=459760

Thanks,
 Enric

> I see that rest of the patchset is already merged and available in 5.9-RC2. 
> 
> Thanks,
> Bilal
> 

Re: [PATCH] Documentation: add minimum clang/llvm version

[Will Deacon]

On Tue, Aug 25, 2020 at 03:25:51PM -0700, Nick Desaulniers wrote:
> Based on a vote at the LLVM BoF at Plumbers 2020, we decided to start
> small, supporting just one formal upstream release of LLVM for now.
> 
> We can probably widen the support window of supported versions over
> time.  Also, note that LLVM's release process is different than GCC's.
> GCC tends to have 1 major release per year while releasing minor updates
> to the past 3 major versions.  LLVM tends to support one major release
> and one minor release every six months.
> 
> Signed-off-by: Nick Desaulniers 
> ---
> Note to reviewers: working remote, I'm having trouble testing/verifying
> that I have the RST links wired up correctly; I would appreciate it if
> someone is able to `make htmldocs` and check
> Documentation/output/process/changes.html properly links to
> Documentation/output/kbuild/llvm.html.
> 
>  Documentation/kbuild/llvm.rst |  2 ++
>  Documentation/process/changes.rst | 10 ++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
> index 2aac50b97921..70ec6e9a183b 100644
> --- a/Documentation/kbuild/llvm.rst
> +++ b/Documentation/kbuild/llvm.rst
> @@ -1,3 +1,5 @@
> +.. _kbuild_llvm:
> +
>  ==
>  Building Linux with Clang/LLVM
>  ==
> diff --git a/Documentation/process/changes.rst 
> b/Documentation/process/changes.rst
> index ee741763a3fc..6c580ef9f2a3 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -30,6 +30,7 @@ you probably needn't concern yourself with pcmciautils.
>  ProgramMinimal version   Command to check the version
>  == ===  
> 
>  GNU C  4.9  gcc --version
> +Clang/LLVM (optional)  10.0.1   clang --version
>  GNU make   3.81 make --version
>  binutils   2.23 ld -v
>  flex   2.5.35   flex --version
> @@ -68,6 +69,15 @@ GCC
>  The gcc version requirements may vary depending on the type of CPU in your
>  computer.
>  
> +Clang/LLVM (optional)
> +-
> +
> +The latest formal release of clang and LLVM utils (according to
> +`releases.llvm.org `_) are supported for building
> +kernels. Older releases aren't gauranteed to work, and we may drop 
> workarounds

typo: guaranteed

Will

Re: [PATCH 4.19 00/71] 4.19.142-rc1 review

[Greg Kroah-Hartman]

On Wed, Aug 26, 2020 at 10:07:32AM +0200, Pavel Machek wrote:
> Hi!
> 
> > This is the start of the stable review cycle for the 4.19.142 release.
> > There are 71 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed, 26 Aug 2020 08:23:34 +.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.142-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> 
> Uh. I believe this was tested successfully by CIP probject:
> 
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/181017473
> 
> Yes, there are two "fails" but there seem to be caused by DNS
> resolution problems (i.e. test infrastructure problem, not kernel problem).

Thanks for testing two of these and letting me know.

greg k-h

[PATCH] Revert "powerpc/powernv/idle: Replace CPU feature check with PVR check"

[Pratik Rajesh Sampat]

Cpuidle stop state implementation has minor optimizations for P10
where hardware preserves more SPR registers compared to P9.
The current P9 driver works for P10, although does few extra
save-restores. P9 driver can provide the required power management
features like SMT thread folding and core level power savings
on a P10 platform.

Until the P10 stop driver is available, revert the commit which
allows for only P9 systems to utilize cpuidle and blocks all
idle stop states for P10.
Cpu idle states are enabled and tested on the P10 platform
with this fix.

This reverts commit 8747bf36f312356f8a295a0c39ff092d65ce75ae.

Fixes: 8747bf36f312 ("powerpc/powernv/idle: Replace CPU feature check with PVR 
check")
Signed-off-by: Pratik Rajesh Sampat 
---
 @mpe: This revert would resolve a staging issue wherein the P10 stop
 driver is not yet ready while cpuidle stop states need not be blocked
 on 5.9 for Power10 systems which could cause SMT folding related
 performance issues.

 The P10 stop driver is in the works here:
 https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216773.html

 arch/powerpc/platforms/powernv/idle.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 77513a80cef9..345ab062b21a 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1223,7 +1223,7 @@ static void __init pnv_probe_idle_states(void)
return;
}
 
-   if (pvr_version_is(PVR_POWER9))
+   if (cpu_has_feature(CPU_FTR_ARCH_300))
pnv_power9_idle_init();
 
for (i = 0; i < nr_pnv_idle_states; i++)
-- 
2.25.4

Re: [PATCH v2] nvmem: mtk-efuse: Remove EFUSE register write support

[andrew-ct chen]

Hi Chih-En,

On Wed, 2020-08-26 at 14:21 +0800, Chih-En Hsu wrote:
> This patch is to remove function "mtk_reg_write" since
> Mediatek EFUSE hardware only supports read functionality
> for NVMEM consumers.

The fixed patch should be ba360fd040e34 ("nvmem: mtk-efuse: remove nvmem
regmap dependency")

> Fixes: 4c7e4fe37766 ("nvmem: mediatek: Add Mediatek EFUSE driver")
> Signed-off-by: Chih-En Hsu 
> ---
>  drivers/nvmem/mtk-efuse.c | 14 --
>  1 file changed, 14 deletions(-)
> 
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 856d9c3fc38e..6a537d959f14 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
>   return 0;
>  }
>  
> -static int mtk_reg_write(void *context,
> -  unsigned int reg, void *_val, size_t bytes)
> -{
> - struct mtk_efuse_priv *priv = context;
> - u32 *val = _val;
> - int i = 0, words = bytes / 4;
> -
> - while (words--)
> - writel(*val++, priv->base + reg + (i++ * 4));
> -
> - return 0;
> -}
> -
>  static int mtk_efuse_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
> @@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
>   econfig.stride = 4;
>   econfig.word_size = 4;
>   econfig.reg_read = mtk_reg_read;
> - econfig.reg_write = mtk_reg_write;
>   econfig.size = resource_size(res);
>   econfig.priv = priv;
>   econfig.dev = dev;

Re: [PATCH v2 00/20] ALSA: hda/ca0132 - Add AE-7 support/Control cleanup.

[Takashi Iwai]

On Tue, 25 Aug 2020 22:10:19 +0200,
Connor McAdams wrote:
> 
> This patch series adds support for the Sound Blaster AE-7 along with
> adding new controls and cleaning up the old ones. I have personally
> tested the Recon3D, Recon3Di, Sound Blaster Z/ZxR, and AE-5 cards to
> confirm they work with these patches. Another user has confirmed that
> they work on the AE-7.
> 
> ---
> v2: Change control names to omit unnecessary information.
> 
> Connor McAdams (20):
>   ALSA: hda/ca0132 - Cleanup ca0132_mmio_init function.
>   ALSA: hda/ca0132 - Add speaker tuning initialization commands.
>   ALSA: hda/ca0132 - Add surround channel config control.
>   ALSA: hda/ca0132 - Add full-range speaker selection controls.
>   ALSA: hda/ca0132 - Add bass redirection controls.
>   ALSA: hda/ca0132 - Remove surround output selection.
>   ALSA: hda/ca0132 - Clean up ca0132_alt_out_select.
>   ALSA: hda/ca0132 - Add quirk output selection structures.
>   ALSA: hda/ca0132 - Fix Recon3D Center/LFE output.
>   ALSA: hda/ca0132 - Add new quirk ID for SoundBlaster AE-7.
>   ALSA: hda/ca0132 - Add SoundBlaster AE-7 pincfg.
>   ALSA: hda/ca0132 - Set AE-7 bools and select mixer.
>   ALSA: hda/ca0132 - Add ca0132_mmio_init data for SoundBlaster AE-7.
>   ALSA: hda/ca0132 - Add pre-init function for SoundBlaster AE-7.
>   ALSA: hda/ca0132 - Add init data for SoundBlaster AE-7.
>   ALSA: hda/ca0132 - Add DSP setup functions for AE-7.
>   ALSA: hda/ca0132 - Add output selection for SoundBlaster AE-7.
>   ALSA: hda/ca0132 - Add AE-7 microphone selection commands.
>   ALSA: hda/ca0132 - Add AE-7 custom controls.
>   ALSA: hda/ca0132 - Add AE-7 exit commands.

Applied all 20 patches now.  Thanks.


Takashi

Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core

[Stephan Gerhold]

On Tue, Aug 25, 2020 at 02:42:54PM +0200, Ulf Hansson wrote:
> On Tue, 25 Aug 2020 at 09:34, Stephan Gerhold  wrote:
> >
> > On Tue, Aug 25, 2020 at 08:43:42AM +0200, Ulf Hansson wrote:
> > > On Tue, 25 Aug 2020 at 06:43, Viresh Kumar  
> > > wrote:
> > > >
> > > > On 24-08-20, 17:08, Stephan Gerhold wrote:
> > > > > On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote:
> > > > > > That said, perhaps should rely on the consumer to deploy runtime PM
> > > > > > support, but let the OPP core to set up the device links for the 
> > > > > > genpd
> > > > > > virtual devices!?
> > > > > >
> > > > >
> > > > > Yes, that would be the alternative option.
> > > >
> > > > That is the right option IMO.
> > > >
> > > > > I would be fine with it as long as it also works for the CPUfreq case.
> > > > >
> > > > > I don't think anything manages runtime PM for the CPU device, just
> > > > > like no-one calls dev_pm_opp_set_rate(cpu_dev, 0). So with my patch 
> > > > > the
> > > > > power domain is essentially kept always-on (except for system 
> > > > > suspend).
> > > > > At least in my case this is intended.
> > > > >
> > > > > If device links also keep the power domains on if the consumer device
> > > > > does not make use of runtime PM it should work fine for my case.
> > > >
> > > > With device link, you only need to do rpm enable/disable on the 
> > > > consumer device
> > > > and it will get propagated by itself.
> > >
> > > Note that the default state for the genpd virtual device(s) is that
> > > runtime PM has been enabled for them. This means it's left in runtime
> > > suspended state, which allows its PM domain to be powered off (if all
> > > other devices and child domains for it allow that too, of course).
> > >
> > > >
> > > > > Personally, I think my original patch (without device links) fits 
> > > > > better
> > > > > into the OPP API, for the following two reasons.
> > > > >
> > > > > With device links:
> > > > >
> > > > >   1. Unlike regulators/interconnects, attached power domains would be
> > > > >  controlled by runtime PM instead of dev_pm_opp_set_rate(opp_dev, 
> > > > > 0).
> > > > >
> > > > >   2. ... some driver using OPP tables might not make use of runtime 
> > > > > PM.
> > > > >  In that case, the power domains would stay on the whole time,
> > > > >  even if dev_pm_opp_set_rate(opp_dev, 0) was called.
> > > > >
> > > > > With my patch, the power domain state is directly related to the
> > > > > dev_pm_opp_set_rate(opp_dev, 0) call, which is more intuitive than
> > > > > relying on the runtime PM state in my opinion.
> > > >
> > > > So opp-set-rate isn't in the best of shape TBH, some things are left 
> > > > for the
> > > > drivers while other are done by it. Regulator-enable/disable was moved 
> > > > to it
> > > > some time back as people needed something like that. While on the other 
> > > > hand,
> > > > clk_enable/disable doesn't happen there, nor does rpm enable/disable.
> > > >
> > > > Maybe one day we may want to do that, but lets make sure someone wants 
> > > > to do
> > > > that first.
> > > >
> > > > Anyway, even in that case both of the changes would be required. We 
> > > > must make
> > > > device links nevertheless first. And later on if required, we may want 
> > > > to do rpm
> > > > enable/disable on the consumer device itself.
> > >
> > > This sounds like a reasonable step-by-step approach.
> > >
> > > Then, to create the device links, we should use DL_FLAG_PM_RUNTIME,
> > > DL_FLAG_STATELESS.
> > >
> >
> > OK, I will give this a try later this week.
> >
> > > But whether we should use DL_FLAG_RPM_ACTIVE as well, to initially
> > > runtime resume the supplier (the genpd virtual device), is harder to
> > > know - as that kind of depends on expectations by the consumer device
> > > driver.
> > >
> >
> > I'm not sure I understand the purpose of that flag. I thought we want to
> > link the PM state of the virtual genpd device (supplier) to the PM state
> > of the device of the OPP table (consumer).
> 
> Correct, but this is about synchronizing the initial runtime PM state
> of the consumer and supplier.
> 
> >
> > Shouldn't it just determine the initial state based on the state of the
> > consumer device?
> 
> We could do that. Then something along the lines of the below, should work:
> 
> pm_runtime_get_noresume(consumer) - to prevent runtime suspend, temporarily.
> 
> if(pm_runtime_active(consumer))
> create links with DL_FLAG_RPM_ACTIVE
> else
> create links without DL_FLAG_RPM_ACTIVE
> 
> pm_runtime_put(consumer)
> 

This seems to work as expected, thanks for the suggestion!
I will submit a v2 with that shortly.

Thanks!
Stephan

Re: x86/kprobes: kretprobe fails to triggered if kprobe at function entry is not optimized (trigger by int3 breakpoint)

[Masami Hiramatsu]

Hi Peter,

On Tue, 25 Aug 2020 14:09:11 +0200
pet...@infradead.org wrote:

> 
> @@ -1934,50 +1884,28 @@ unsigned long __weak arch_deref_entry_point(void 
> *entry)
>  static int pre_handler_kretprobe(struct kprobe *p, struct pt_regs *regs)
>  {
>   struct kretprobe *rp = container_of(p, struct kretprobe, kp);
> - unsigned long hash, flags = 0;
>   struct kretprobe_instance *ri;
> + struct llist_node *llist;
>  
> - /*
> -  * To avoid deadlocks, prohibit return probing in NMI contexts,
> -  * just skip the probe and increase the (inexact) 'nmissed'
> -  * statistical counter, so that the user is informed that
> -  * something happened:
> -  */
> - if (unlikely(in_nmi())) {
> + llist = llist_del_first(&rp->free_instances);
> + if (!llist) {
>   rp->nmissed++;
>   return 0;
>   }

Would we need a lock around llist_del_first(&rp->free_instance) here?

linux/llist.h said,

 * Cases where locking is not needed:
 * If there are multiple producers and multiple consumers, llist_add can be
 * used in producers and llist_del_all can be used in consumers simultaneously
 * without locking. Also a single consumer can use llist_del_first while
   ^^^
 * multiple producers simultaneously use llist_add, without any locking.
 *
 * Cases where locking is needed:
 * If we have multiple consumers with llist_del_first used in one consumer, and
 ^^^
 * llist_del_first or llist_del_all used in other consumers, then a lock is
 * needed.

pre_handler_kretprobe() can be invoked simultaneously on the different CPUs
if those are calling the same probed function.


Thank you,

-- 
Masami Hiramatsu 

回复: 回复: [PATCH] debugobjects: install cpu hotplug callback

[Zhang, Qiang]

发件人: linux-kernel-ow...@vger.kernel.org  代表 
Thomas Gleixner 
发送时间: 2020年8月26日 7:53
收件人: Waiman Long; Zhang, Qiang; el...@google.com
抄送: linux-kernel@vger.kernel.org; a...@linux-foundation.org
主题: Re: 回复: [PATCH] debugobjects: install cpu hotplug callback

On Tue, Aug 25 2020 at 18:26, Waiman Long wrote:
> On 8/25/20 12:53 AM, Zhang, Qiang wrote:
>>
>> When a cpu going offline, we should free objects in "percpu_obj_pool"
>> free_objs list which corresponding to this cpu.
>
> The percpu free object pool is supposed to be accessed only by that
> particular cpu without any lock. Trying to access it from another cpu
> can cause a race condition unless one can make sure that the offline cpu
> won't become online in the mean time.

>It is actually safe because CPU hotplug is globally serialized and there
>is no way that an offline CPU will come back from death valley
>magically. If such a zombie ever surfaces then we have surely more
>serious problems than accessing that pool :)

> There shouldn't be too many free objects in the percpu pool. Is it
> worth the effort to free them?

>That's a really good question nevertheless. The only case where this
>ever matters is physical hotplug. All other CPU hotplug stuff is
>temporarily or in case of a late (post boottime) SMT disable it's going
>to be a handful of free objects on that pool. As debugobjects is as the
>name says a debug facility the benefit is questionable unless there is a
>good reason to do so.

 I don't know  there may not be too many objects  in the percpu pool,
 but that doesn't mean they no need to be free, a CPU may never be online after 
it is offline. some objects in percpu pool is never free.



>Thanks,

  >  tglx

Re: [Intel-gfx] 5.9-rc1: graphics regression moved from -next to mainline

[Harald Arnesen]

Linus Torvalds [25.08.2020 20:19]:

> On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen  wrote:
>>
>> > For posterity, I'm told the fix is [1].
>> >
>> > [1] 
>> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>>
>> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
>> freeezes. I can still ssh into the machine
>>
>> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
>> the bug for me.
> 
> Do you get any oops or other indication of what ends up going wrong?
> Since ssh works that should be fairly easy to see.
I was wrong about ssh working. The whole machine locks up when X starts.

A strange thing, sometimes I can log in from lightdm before it locks up,
sometimes I cannot even use the login screen. Timing related?

If I don't start X, console login seems to work fine, and I see nothing
obvious in the logs or kernel messages.

I will try to start just a window manager with startx instead of going
through lightdm.
-- 
Hilsen Harald

[PATCH v2 2/2] drm/amdkfd: Put ACPI table after using it

[Hanjun Guo]

The acpi_get_table() should be coupled with acpi_put_table() if
the mapped table is not used at runtime to release the table
mapping which can prevent the memory leak.

In kfd_create_crat_image_acpi(), crat_table is copied to pcrat_image,
and in kfd_create_vcrat_image_cpu(), the acpi_table is only used to
get the OEM information, so those two table mappings need to be released
after using it.

Fixes: 174de876d6d0 ("drm/amdkfd: Group up CRAT related functions")
Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
Signed-off-by: Hanjun Guo 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index ed77b109..c3f3ffb6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -758,6 +758,7 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
*size)
struct acpi_table_header *crat_table;
acpi_status status;
void *pcrat_image;
+   int rc = 0;
 
if (!crat_image)
return -EINVAL;
@@ -782,13 +783,16 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
*size)
}
 
pcrat_image = kmemdup(crat_table, crat_table->length, GFP_KERNEL);
-   if (!pcrat_image)
-   return -ENOMEM;
+   if (!pcrat_image) {
+   rc = -ENOMEM;
+   goto out;
+   }
 
*crat_image = pcrat_image;
*size = crat_table->length;
-
-   return 0;
+out:
+   acpi_put_table(crat_table);
+   return rc;
 }
 
 /* Memory required to create Virtual CRAT.
@@ -972,6 +976,7 @@ static int kfd_create_vcrat_image_cpu(void *pcrat_image, 
size_t *size)
CRAT_OEMID_LENGTH);
memcpy(crat_table->oem_table_id, acpi_table->oem_table_id,
CRAT_OEMTABLEID_LENGTH);
+   acpi_put_table(acpi_table);
}
crat_table->total_entries = 0;
crat_table->num_domains = 0;
-- 
1.7.12.4

[PATCH v2 1/2] drm/amdkfd: Move the ignore_crat check before the CRAT table get

[Hanjun Guo]

If the ignore_crat is set to non-zero value, it's no point getting
the CRAT table, so just move the ignore_crat check before we get the
CRAT table.

Signed-off-by: Hanjun Guo 
---
 drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 6a250f8..ed77b109 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -764,6 +764,11 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
*size)
 
*crat_image = NULL;
 
+   if (ignore_crat) {
+   pr_info("CRAT table disabled by module option\n");
+   return -ENODATA;
+   }
+
/* Fetch the CRAT table from ACPI */
status = acpi_get_table(CRAT_SIGNATURE, 0, &crat_table);
if (status == AE_NOT_FOUND) {
@@ -776,11 +781,6 @@ int kfd_create_crat_image_acpi(void **crat_image, size_t 
*size)
return -EINVAL;
}
 
-   if (ignore_crat) {
-   pr_info("CRAT table disabled by module option\n");
-   return -ENODATA;
-   }
-
pcrat_image = kmemdup(crat_table, crat_table->length, GFP_KERNEL);
if (!pcrat_image)
return -ENOMEM;
-- 
1.7.12.4

Re: [PATCH] Revert "powerpc/powernv/idle: Replace CPU feature check with PVR check"

[Christophe Leroy]

Le 26/08/2020 à 10:29, Pratik Rajesh Sampat a écrit :

Cpuidle stop state implementation has minor optimizations for P10
where hardware preserves more SPR registers compared to P9.
The current P9 driver works for P10, although does few extra
save-restores. P9 driver can provide the required power management
features like SMT thread folding and core level power savings
on a P10 platform.

Until the P10 stop driver is available, revert the commit which
allows for only P9 systems to utilize cpuidle and blocks all
idle stop states for P10.
Cpu idle states are enabled and tested on the P10 platform
with this fix.

This reverts commit 8747bf36f312356f8a295a0c39ff092d65ce75ae.

Fixes: 8747bf36f312 ("powerpc/powernv/idle: Replace CPU feature check with PVR 
check")
Signed-off-by: Pratik Rajesh Sampat 
---
  @mpe: This revert would resolve a staging issue wherein the P10 stop
  driver is not yet ready while cpuidle stop states need not be blocked
  on 5.9 for Power10 systems which could cause SMT folding related
  performance issues.

  The P10 stop driver is in the works here:
  https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216773.html

  arch/powerpc/platforms/powernv/idle.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/idle.c 
b/arch/powerpc/platforms/powernv/idle.c
index 77513a80cef9..345ab062b21a 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -1223,7 +1223,7 @@ static void __init pnv_probe_idle_states(void)
return;
}
  
-	if (pvr_version_is(PVR_POWER9))

+   if (cpu_has_feature(CPU_FTR_ARCH_300))


Why not something like:

if (pvr_version_is(PVR_POWER9) || pvr_version_is(PVR_POWER10))
pnv_power9_idle_init();



pnv_power9_idle_init();
  
  	for (i = 0; i < nr_pnv_idle_states; i++)




Christophe

RE: [PATCH 00/13] lib/generic-radix-tree: genradix bug fix and optimisations.

[David Laight]

From: David Laight
> Sent: 26 August 2020 08:36
...
> I'm going to try marking the lookup functions with '__attribute__ ((pure))'.
> That should help the sctp code that does repeated SCTP_SI().
> In reality I want to mark them __attribute__ ((const)) - including the
> inline wrappers, but that isn't allowed if they read memory.

Neither pure nor const makes any difference.
Even to code that like:
if (SCTP_SO(...)->ext)
SCTP_SO(...)->ext->foo = 0;

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [PATCH v2] nvmem: mtk-efuse: Remove EFUSE register write support

[Chih-En Hsu]

Hi Andrew:

OK, I will fix it.

Thanks a lot.

Alex

On Wed, 2020-08-26 at 16:30 +0800, andrew-ct chen wrote:
> Hi Chih-En,
> 
> On Wed, 2020-08-26 at 14:21 +0800, Chih-En Hsu wrote:
> > This patch is to remove function "mtk_reg_write" since
> > Mediatek EFUSE hardware only supports read functionality
> > for NVMEM consumers.
> 
> The fixed patch should be ba360fd040e34 ("nvmem: mtk-efuse: remove nvmem
> regmap dependency")
> 
> > Fixes: 4c7e4fe37766 ("nvmem: mediatek: Add Mediatek EFUSE driver")
> > Signed-off-by: Chih-En Hsu 
> > ---
> >  drivers/nvmem/mtk-efuse.c | 14 --
> >  1 file changed, 14 deletions(-)
> > 
> > diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> > index 856d9c3fc38e..6a537d959f14 100644
> > --- a/drivers/nvmem/mtk-efuse.c
> > +++ b/drivers/nvmem/mtk-efuse.c
> > @@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
> > return 0;
> >  }
> >  
> > -static int mtk_reg_write(void *context,
> > -unsigned int reg, void *_val, size_t bytes)
> > -{
> > -   struct mtk_efuse_priv *priv = context;
> > -   u32 *val = _val;
> > -   int i = 0, words = bytes / 4;
> > -
> > -   while (words--)
> > -   writel(*val++, priv->base + reg + (i++ * 4));
> > -
> > -   return 0;
> > -}
> > -
> >  static int mtk_efuse_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = &pdev->dev;
> > @@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> > econfig.stride = 4;
> > econfig.word_size = 4;
> > econfig.reg_read = mtk_reg_read;
> > -   econfig.reg_write = mtk_reg_write;
> > econfig.size = resource_size(res);
> > econfig.priv = priv;
> > econfig.dev = dev;
> 
> 

Re: [PATCH v2 5/7][next] printk: ringbuffer: add finalization/extension support

[John Ogness]

On 2020-08-24, John Ogness  wrote:
> @@ -1157,6 +1431,14 @@ bool prb_reserve(struct prb_reserved_entry *e, struct 
> printk_ringbuffer *rb,
>   goto fail;
>   }
>  
> + /*
> +  * New data is about to be reserved. Once that happens, previous
> +  * descriptors are no longer able to be extended. Finalize the
> +  * previous descriptor now so that it can be made available to
> +  * readers (when committed).
> +  */
> + desc_finalize(desc_ring, DESC_ID(id - 1));
> +
>   d = to_desc(desc_ring, id);
>  
>   /*

Apparently this is not enough to guarantee that past descriptors are
finalized. I am able to reproduce a scenario where the finalization of a
certain descriptor never happens. That leaves the descriptor permanently
in the reserved queried state, which prevents any new records from being
created. I am investigating.

John Ogness

[PATCH] arm64: dts: sparx5: Fix Sparx5 SDHCI node name

[Lars Povlsen]

This patch corrects the SDHCI node name to conform with the devicetree
specification ("mmc0@60080" => "mmc@60080").

Signed-off-by: Lars Povlsen 
---
 arch/arm64/boot/dts/microchip/sparx5.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi 
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index a79c5bb10ab2..d477fcb57e64 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -152,7 +152,7 @@ timer1: timer@600105000 {
interrupts = ;
};

-   sdhci0: mmc0@60080 {
+   sdhci0: mmc@60080 {
compatible = "microchip,dw-sparx5-sdhci";
status = "disabled";
reg = <0x6 0x0080 0x1000>;
--
2.27.0

Re: [patch RFC 10/38] x86/ioapic: Consolidate IOAPIC allocation

[Boqun Feng]

Hi Thomas,

I hit a compiler error while I was trying to compile this patchset:

arch/x86/kernel/devicetree.c: In function ‘dt_irqdomain_alloc’:
arch/x86/kernel/devicetree.c:232:6: error: ‘struct irq_alloc_info’ has no 
member named ‘ioapic_id’; did you mean ‘ioapic’?
  232 |  tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
  |  ^
  |  ioapic
arch/x86/kernel/devicetree.c:233:6: error: ‘struct irq_alloc_info’ has no 
member named ‘ioapic_pin’; did you mean ‘ioapic’?
  233 |  tmp.ioapic_pin = fwspec->param[0]
  |  ^~
  |  ioapic

with CONFIG_OF=y. IIUC, the following changes are needed to fold into
this patch. (At least I can continue to compile the kernel with this
change)

diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
index a0e8fc7d85f1..ddffd80f5c52 100644
--- a/arch/x86/kernel/devicetree.c
+++ b/arch/x86/kernel/devicetree.c
@@ -229,8 +229,8 @@ static int dt_irqdomain_alloc(struct irq_domain *domain, 
unsigned int virq,
 
it = &of_ioapic_type[type_index];
ioapic_set_alloc_attr(&tmp, NUMA_NO_NODE, it->trigger, it->polarity);
-   tmp.ioapic_id = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
-   tmp.ioapic_pin = fwspec->param[0];
+   tmp.devid = mpc_ioapic_id(mp_irqdomain_ioapic_idx(domain));
+   tmp.ioapic.pin = fwspec->param[0];
 
return mp_irqdomain_alloc(domain, virq, nr_irqs, &tmp);
 }

Regards,
Boqun

On Fri, Aug 21, 2020 at 02:24:34AM +0200, Thomas Gleixner wrote:
> Move the IOAPIC specific fields into their own struct and reuse the common
> devid. Get rid of the #ifdeffery as it does not matter at all whether the
> alloc info is a couple of bytes longer or not.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Wei Liu 
> Cc: "K. Y. Srinivasan" 
> Cc: Stephen Hemminger 
> Cc: Joerg Roedel 
> Cc: linux-hyp...@vger.kernel.org
> Cc: io...@lists.linux-foundation.org
> Cc: Haiyang Zhang 
> Cc: Jon Derrick 
> Cc: Lu Baolu 
> ---
>  arch/x86/include/asm/hw_irq.h   |   23 ++-
>  arch/x86/kernel/apic/io_apic.c  |   70 
> ++--
>  drivers/iommu/amd/iommu.c   |   14 +++
>  drivers/iommu/hyperv-iommu.c|2 -
>  drivers/iommu/intel/irq_remapping.c |   18 -
>  5 files changed, 64 insertions(+), 63 deletions(-)
> 
> --- a/arch/x86/include/asm/hw_irq.h
> +++ b/arch/x86/include/asm/hw_irq.h
> @@ -44,6 +44,15 @@ enum irq_alloc_type {
>   X86_IRQ_ALLOC_TYPE_HPET_GET_PARENT,
>  };
>  
> +struct ioapic_alloc_info {
> + int pin;
> + int node;
> + u32 trigger : 1;
> + u32 polarity : 1;
> + u32 valid : 1;
> + struct IO_APIC_route_entry  *entry;
> +};
> +
>  /**
>   * irq_alloc_info - X86 specific interrupt allocation info
>   * @type:X86 specific allocation type
> @@ -53,6 +62,8 @@ enum irq_alloc_type {
>   * @mask:CPU mask for vector allocation
>   * @desc:Pointer to msi descriptor
>   * @data:Allocation specific data
> + *
> + * @ioapic:  IOAPIC specific allocation data
>   */
>  struct irq_alloc_info {
>   enum irq_alloc_type type;
> @@ -64,6 +75,7 @@ struct irq_alloc_info {
>   void*data;
>  
>   union {
> + struct ioapic_alloc_infoioapic;
>   int unused;
>  #ifdef   CONFIG_PCI_MSI
>   struct {
> @@ -71,17 +83,6 @@ struct irq_alloc_info {
>   irq_hw_number_t msi_hwirq;
>   };
>  #endif
> -#ifdef   CONFIG_X86_IO_APIC
> - struct {
> - int ioapic_id;
> - int ioapic_pin;
> - int ioapic_node;
> - u32 ioapic_trigger : 1;
> - u32 ioapic_polarity : 1;
> - u32 ioapic_valid : 1;
> - struct IO_APIC_route_entry *ioapic_entry;
> - };
> -#endif
>  #ifdef   CONFIG_DMAR_TABLE
>   struct {
>   int dmar_id;
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -860,10 +860,10 @@ void ioapic_set_alloc_attr(struct irq_al
>  {
>   init_irq_alloc_info(info, NULL);
>   info->type = X86_IRQ_ALLOC_TYPE_IOAPIC;
> - info->ioapic_node = node;
> - info->ioapic_trigger = trigger;
> - info->ioapic_polarity = polarity;
> - info->ioapic_valid = 1;
> + info->ioapic.node = node;
> + info->ioapic.trigger = trigger;
> + info->ioapic.polarity = polarity;
> + info->ioapic.valid = 1;
>  }
>  
>  #ifndef CONFIG_ACPI
> @@ -878,32 +878,32 @@ static void ioapic_copy_alloc_attr(struc
>  
>   copy_irq_alloc_info(dst, src);
>   dst->type = X86_IRQ_ALLOC_TYPE_IOAPIC;
> - dst->ioapic_id = mpc_ioapi

[PATCH v3] nvmem: mtk-efuse: Remove EFUSE register write support

[Chih-En Hsu]

This patch is to remove function "mtk_reg_write" since
Mediatek EFUSE hardware only supports read functionality
for NVMEM consumers.

Fixes: ba360fd040e3 ("nvmem: mtk-efuse: remove nvmem regmap dependency")
Signed-off-by: Chih-En Hsu 
---
 drivers/nvmem/mtk-efuse.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 856d9c3fc38e..6a537d959f14 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -28,19 +28,6 @@ static int mtk_reg_read(void *context,
return 0;
 }
 
-static int mtk_reg_write(void *context,
-unsigned int reg, void *_val, size_t bytes)
-{
-   struct mtk_efuse_priv *priv = context;
-   u32 *val = _val;
-   int i = 0, words = bytes / 4;
-
-   while (words--)
-   writel(*val++, priv->base + reg + (i++ * 4));
-
-   return 0;
-}
-
 static int mtk_efuse_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -61,7 +48,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
econfig.stride = 4;
econfig.word_size = 4;
econfig.reg_read = mtk_reg_read;
-   econfig.reg_write = mtk_reg_write;
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-- 
2.18.0

[PATCH] ALSA: hda/realtek: Add quirk for Samsung Galaxy Book Ion NT950XCJ-X716A

[Adrien Crivelli]

The Galaxy Book Ion NT950XCJ-X716A (15 inches) uses the same ALC298
codec as other Samsung laptops which have the no headphone sound bug. I
confirmed on my own hardware that this fixes the bug.

This also correct the model name for the 13 inches version. It was
incorrectly referenced as NT950XCJ-X716A in commit e17f02d05. But it
should have been NP930XCJ-K01US.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423
Signed-off-by: Adrien Crivelli 
---
 sound/pci/hda/patch_realtek.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a1fa983d2..98789691a 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -7695,7 +7695,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x144d, 0xc169, "Samsung Notebook 9 Pen 
(NP930SBE-K01US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x144d, 0xc176, "Samsung Notebook 9 Pro 
(NP930MBE-K04US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x144d, 0xc189, "Samsung Galaxy Flex Book 
(NT950QCG-X716)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
-   SND_PCI_QUIRK(0x144d, 0xc18a, "Samsung Galaxy Book Ion 
(NT950XCJ-X716A)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
+   SND_PCI_QUIRK(0x144d, 0xc18a, "Samsung Galaxy Book Ion 
(NP930XCJ-K01US)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
+   SND_PCI_QUIRK(0x144d, 0xc830, "Samsung Galaxy Book Ion 
(NT950XCJ-X716A)", ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x144d, 0xc740, "Samsung Ativ book 8 (NP870Z5G)", 
ALC269_FIXUP_ATIV_BOOK_8),
SND_PCI_QUIRK(0x144d, 0xc812, "Samsung Notebook Pen S (NT950SBE-X58)", 
ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET),
SND_PCI_QUIRK(0x1458, 0xfa53, "Gigabyte BXBT-2807", 
ALC283_FIXUP_HEADSET_MIC),
-- 
2.25.1

[PATCH v6] dt-bindings: mmc: Add Sparx5 SDHCI controller bindings

[Lars Povlsen]

The Sparx5 SDHCI controller is based on the Designware controller IP.

Signed-off-by: Lars Povlsen 
---

Note: This patch is now separated from original patch series.

v6 changes:
- Change "mmc0@60080" => "mmc@60080"

[from earlier patch series, only applicable changes]

Changes in v5:
- Change (mmc|sdhci)@60080 to mmc0@60080

Changes in v4:
n/a

Changes in v3:
- Add dt-bindings for property "microchip,clock-delay"

Changes in v2:
n/a

 .../mmc/microchip,dw-sparx5-sdhci.yaml| 65 +++
 1 file changed, 65 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml

diff --git 
a/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml 
b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
new file mode 100644
index ..55883290543b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/microchip,dw-sparx5-sdhci.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/microchip,dw-sparx5-sdhci.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Mobile Storage Host Controller Binding
+
+allOf:
+  - $ref: "mmc-controller.yaml"
+
+maintainers:
+  - Lars Povlsen 
+
+# Everything else is described in the common file
+properties:
+  compatible:
+const: microchip,dw-sparx5-sdhci
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+description:
+  Handle to "core" clock for the sdhci controller.
+
+  clock-names:
+items:
+  - const: core
+
+  microchip,clock-delay:
+description: Delay clock to card to meet setup time requirements.
+  Each step increase by 1.25ns.
+$ref: "/schemas/types.yaml#/definitions/uint32"
+minimum: 1
+maximum: 15
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+examples:
+  - |
+#include 
+#include 
+sdhci0: mmc@60080 {
+compatible = "microchip,dw-sparx5-sdhci";
+reg = <0x0080 0x1000>;
+pinctrl-0 = <&emmc_pins>;
+pinctrl-names = "default";
+clocks = <&clks CLK_ID_AUX1>;
+clock-names = "core";
+assigned-clocks = <&clks CLK_ID_AUX1>;
+assigned-clock-rates = <8>;
+interrupts = ;
+bus-width = <8>;
+microchip,clock-delay = <10>;
+};
--
2.27.0

Re: [PATCH v2] soundwire: intel: fix intel_suspend/resume defined but not used warning

[Vinod Koul]

On 24-08-20, 21:32, Bard Liao wrote:
> When CONFIG_PM_SLEEP is not defined, GCC throws compilation warnings:
> 
> drivers/soundwire/intel.c:1799:12: warning: ‘intel_resume’ defined but not
> used [-Wunused-function]
>  static int intel_resume(struct device *dev)
> ^~~~
> drivers/soundwire/intel.c:1683:12: warning: ‘intel_suspend’ defined but not
> used [-Wunused-function]
>  static int intel_suspend(struct device *dev)
> ^
> 
> Fix by using __maybe_unused macro.

Applied, thanks

-- 
~Vinod

Re: [PATCH] ALSA: hda/realtek: Add quirk for Samsung Galaxy Book Ion NT950XCJ-X716A

[Takashi Iwai]

On Wed, 26 Aug 2020 10:40:14 +0200,
Adrien Crivelli wrote:
> 
> The Galaxy Book Ion NT950XCJ-X716A (15 inches) uses the same ALC298
> codec as other Samsung laptops which have the no headphone sound bug. I
> confirmed on my own hardware that this fixes the bug.
> 
> This also correct the model name for the 13 inches version. It was
> incorrectly referenced as NT950XCJ-X716A in commit e17f02d05. But it
> should have been NP930XCJ-K01US.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423
> Signed-off-by: Adrien Crivelli 

Thanks, applied.


Takashi

[PATCH] drm/mgag200: fix spelling mistake "expeced" -> "expected"

[Colin King]

From: Colin Ian King 

There is a spelling mistake in a drm_warn message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index b282b0e42c2d..771b26aeee19 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -168,7 +168,7 @@ static void mgag200_g200_interpret_bios(struct mga_device 
*mdev,
return;
}
if (pins_len != expected_length[version]) {
-   drm_warn(dev, "Unexpected BIOS PInS size: %d expeced: %d\n",
+   drm_warn(dev, "Unexpected BIOS PInS size: %d expected: %d\n",
 pins_len, expected_length[version]);
return;
}
-- 
2.27.0

Re: [PATCH] m68k: Replace HTTP links with HTTPS ones

[Geert Uytterhoeven]

Hi Alexander,

Thanks for your patch!

On Fri, Jul 17, 2020 at 8:42 PM Alexander A. Klimov
 wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>   If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:

Something must be wrong with your script, as several of them return
"301 Moved Permanently" instead of "200 OK".

>   Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov 

> --- a/arch/m68k/include/asm/mac_via.h
> +++ b/arch/m68k/include/asm/mac_via.h
> @@ -30,7 +30,7 @@
>   *  http://www.rs6000.ibm.com/resource/technology/chrpio/via5.mak.html
>   *  
> ftp://ftp.austin.ibm.com/pub/technology/spec/chrp/inwork/CHRP_IORef_1.0.pdf
>   *
> - * also, http://developer.apple.com/technotes/hw/hw_09.html claims the
> + * also, https://developer.apple.com/technotes/hw/hw_09.html claims the

No longer contains the original content.  Perhaps it should be replaced by
https://web.archive.org/web/20041012040104/http://developer.apple.com/technotes/hw/hw_09.html
instead?

>   * following changes for IIfx:
>   * VIA1A_vSccWrReq not available and that VIA1A_vSync has moved to an IOP.
>   * Also, "All of the functionality of VIA2 has been moved to other chips".
> @@ -178,7 +178,7 @@
>  * on others, 0=disable processor's 
> instruction
>  * and data caches. */
>
> -/* Apple sez: http://developer.apple.com/technotes/ov/ov_04.html
> +/* Apple sez: https://developer.apple.com/technotes/ov/ov_04.html

Probably the same, didn't bother to dive into web.archive.org.

>   * Another example of a valid function that has no ROM support is the use
>   * of the alternate video page for page-flipping animation. Since there
>   * is no ROM call to flip pages, it is necessary to go play with the
> diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
> index 5c9f3a2d6538..6f2eb1dcfc0c 100644
> --- a/arch/m68k/mac/config.c
> +++ b/arch/m68k/mac/config.c
> @@ -240,7 +240,7 @@ static struct mac_model mac_data_table[] = {
>  * Weirdified Mac II hardware - all subtly different. Gee thanks
>  * Apple. All these boxes seem to have VIA2 in a different place to
>  * the Mac II (+1A000 rather than +4000)
> -* CSA: see http://developer.apple.com/technotes/hw/hw_09.html
> +* CSA: see https://developer.apple.com/technotes/hw/hw_09.html

Same as above.

>  */
>
> {
> diff --git a/arch/m68k/mac/macboing.c b/arch/m68k/mac/macboing.c
> index 388780797f7d..a904146dc4e6 100644
> --- a/arch/m68k/mac/macboing.c
> +++ b/arch/m68k/mac/macboing.c
> @@ -116,7 +116,7 @@ static void mac_init_asc( void )
>  *   support 16-bit stereo output, but only mono 
> input."
>  *
>  *   Technical Information Library (TIL) article 
> number 16405.
> -*   http://support.apple.com/kb/TA32601
> +*   https://support.apple.com/kb/TA32601

This change is fine. Actually the old URL returns 301 to point to the
new URL ;-)

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/1] EDAC/ghes: Fix for NULL pointer dereference in ghes_edac_register()

[Borislav Petkov]

On Tue, Aug 25, 2020 at 02:01:08PM +0100, Shiju Jose wrote:
> After the 'commit b9cae27728d1 ("EDAC/ghes: Scan the system once on driver 
> init")'
> applied, following error has occurred in ghes_edac_register() when
> CONFIG_DEBUG_TEST_DRIVER_REMOVE is enabled. The null ghes_hw.dimms pointer
> in the mci_for_each_dimm() of ghes_edac_register() caused the error.
> 
> The error occurs when all the previously initialized ghes instances are
> removed and then probe a new ghes instance. In this case, the ghes_refcount
> would be 0, ghes_hw.dimms and mci already freed. The ghes_hw.dimms would
> be null because ghes_scan_system() would not call enumerate_dimms() again.

Try the below instead and see if it fixes the issue for you too.

If it does, pls send it as v2 but do not add the splat to the commit
message - that's a lot of noise for something which is clear why it
happens and you explain it properly in text anyway.

Thx.

---
diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
index da60c29468a7..54ebc8afc6b1 100644
--- a/drivers/edac/ghes_edac.c
+++ b/drivers/edac/ghes_edac.c
@@ -55,6 +55,8 @@ static DEFINE_SPINLOCK(ghes_lock);
 static bool __read_mostly force_load;
 module_param(force_load, bool, 0);
 
+static bool system_scanned;
+
 /* Memory Device - Type 17 of SMBIOS spec */
 struct memdev_dmi_entry {
u8 type;
@@ -225,14 +227,12 @@ static void enumerate_dimms(const struct dmi_header *dh, 
void *arg)
 
 static void ghes_scan_system(void)
 {
-   static bool scanned;
-
-   if (scanned)
+   if (system_scanned)
return;
 
dmi_walk(enumerate_dimms, &ghes_hw);
 
-   scanned = true;
+   system_scanned = true;
 }
 
 void ghes_edac_report_mem_error(int sev, struct cper_sec_mem_err *mem_err)
@@ -631,6 +631,8 @@ void ghes_edac_unregister(struct ghes *ghes)
 
mutex_lock(&ghes_reg_mutex);
 
+   system_scanned = false;
+
if (!refcount_dec_and_test(&ghes_refcount))
goto unlock;
 

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

[RESEND PATCH v2 2/2] drm/mediatek: mtk_dpi: Convert to bridge driver

[Enric Balletbo i Serra]

Convert mtk_dpi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

 drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index f7372dbdac0e..589ef33a1780 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,6 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
+   struct drm_bridge bridge;
struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
@@ -83,9 +84,9 @@ struct mtk_dpi {
int refcount;
 };
 
-static inline struct mtk_dpi *mtk_dpi_from_encoder(struct drm_encoder *e)
+static inline struct mtk_dpi *bridge_to_dpi(struct drm_bridge *b)
 {
-   return container_of(e, struct mtk_dpi, encoder);
+   return container_of(b, struct mtk_dpi, bridge);
 }
 
 enum mtk_dpi_polarity {
@@ -521,50 +522,53 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
return 0;
 }
 
-static bool mtk_dpi_encoder_mode_fixup(struct drm_encoder *encoder,
-  const struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
+static void mtk_dpi_encoder_destroy(struct drm_encoder *encoder)
 {
-   return true;
+   drm_encoder_cleanup(encoder);
 }
 
-static void mtk_dpi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
+static const struct drm_encoder_funcs mtk_dpi_encoder_funcs = {
+   .destroy = mtk_dpi_encoder_destroy,
+};
+
+static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+
+   return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
+&dpi->bridge, flags);
+}
+
+static void mtk_dpi_bridge_mode_set(struct drm_bridge *bridge,
+   const struct drm_display_mode *mode,
+   const struct drm_display_mode *adjusted_mode)
+{
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
drm_mode_copy(&dpi->mode, adjusted_mode);
 }
 
-static void mtk_dpi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_disable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_off(dpi);
 }
 
-static void mtk_dpi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dpi_bridge_enable(struct drm_bridge *bridge)
 {
-   struct mtk_dpi *dpi = mtk_dpi_from_encoder(encoder);
+   struct mtk_dpi *dpi = bridge_to_dpi(bridge);
 
mtk_dpi_power_on(dpi);
mtk_dpi_set_display_mode(dpi, &dpi->mode);
 }
 
-static int mtk_dpi_atomic_check(struct drm_encoder *encoder,
-   struct drm_crtc_state *crtc_state,
-   struct drm_connector_state *conn_state)
-{
-   return 0;
-}
-
-static const struct drm_encoder_helper_funcs mtk_dpi_encoder_helper_funcs = {
-   .mode_fixup = mtk_dpi_encoder_mode_fixup,
-   .mode_set = mtk_dpi_encoder_mode_set,
-   .disable = mtk_dpi_encoder_disable,
-   .enable = mtk_dpi_encoder_enable,
-   .atomic_check = mtk_dpi_atomic_check,
+static const struct drm_bridge_funcs mtk_dpi_bridge_funcs = {
+   .attach = mtk_dpi_bridge_attach,
+   .mode_set = mtk_dpi_bridge_mode_set,
+   .disable = mtk_dpi_bridge_disable,
+   .enable = mtk_dpi_bridge_enable,
 };
 
 static void mtk_dpi_start(struct mtk_ddp_comp *comp)
@@ -605,12 +609,11 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
dev_err(dev, "Failed to initialize decoder: %d\n", ret);
goto err_unregister;
}
-   drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
 
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
+   ret = drm_bridge_attach(&dpi->encoder, &dpi->bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -791,8 +794,15 @@ static int mtk_dpi_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, dpi);
 
+   dpi->bridge.funcs = &mtk_dpi_bridge_func

[RESEND PATCH v2 1/2] drm/mediatek: mtk_dpi: Rename bridge to next_bridge

[Enric Balletbo i Serra]

This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.

Reviewed-by: Chun-Kuang Hu 
Signed-off-by: Enric Balletbo i Serra 
---

Changes in v2: None

 drivers/gpu/drm/mediatek/mtk_dpi.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index d4f0fb7ad312..f7372dbdac0e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -64,7 +64,7 @@ enum mtk_dpi_out_color_format {
 struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
-   struct drm_bridge *bridge;
+   struct drm_bridge *next_bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -610,7 +610,7 @@ static int mtk_dpi_bind(struct device *dev, struct device 
*master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
 
-   ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL, 0);
+   ret = drm_bridge_attach(&dpi->encoder, dpi->next_bridge, NULL, 0);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -770,11 +770,11 @@ static int mtk_dpi_probe(struct platform_device *pdev)
}
 
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- NULL, &dpi->bridge);
+ NULL, &dpi->next_bridge);
if (ret)
return ret;
 
-   dev_info(dev, "Found bridge node: %pOF\n", dpi->bridge->of_node);
+   dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
 
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
if (comp_id < 0) {
-- 
2.28.0

[RESEND PATCH v2 0/2] Convert mtk-dpi to drm_bridge API

[Enric Balletbo i Serra]

The mtk-dpi driver still uses the drm_encoder API which is now somewhat
deprecated. We started to move all the Mediatek drivers to the drm_bridge API,
like we did for the mtk-dsi driver [1], this is another small step to be able to
fully convert the DRM Mediatek drivers to the drm_bridge API. A dummy
drm_encoder is maintained in the mtk-dpi driver but the end goal is move all the
dummy drm_encoder (mtk-dsi, mtk-dpi, etc) to the main mtk_drm_drv driver.

[1] https://lore.kernel.org/patchwork/project/lkml/list/?series=441559

Changes in v2:
- Maintain error message when attach to bridge fails. (Boris)

Enric Balletbo i Serra (2):
  drm/mediatek: mtk_dpi: Rename bridge to next_bridge
  drm/mediatek: mtk_dpi: Convert to bridge driver

 drivers/gpu/drm/mediatek/mtk_dpi.c | 77 +-
 1 file changed, 45 insertions(+), 32 deletions(-)

-- 
2.28.0

[PATCH v2] dt-bindings: spi: Convert spi-mtk-nor to json-schema

[Ikjoon Jang]

Convert Mediatek ARM SOC's serial NOR flash controller binding
to json-schema format.

Signed-off-by: Ikjoon Jang 
---
v2: remove unnecessary quotes, set interrupts as required,
add unevaluatedProperties:false
---
 .../bindings/spi/mediatek,spi-mtk-nor.yaml| 85 +++
 .../devicetree/bindings/spi/spi-mtk-nor.txt   | 47 --
 2 files changed, 85 insertions(+), 47 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-mtk-nor.txt

diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml 
b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
new file mode 100644
index ..42c9205ac991
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/mediatek,spi-mtk-nor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Serial NOR flash controller for MediaTek ARM SoCs
+
+maintainers:
+  - Bayi Cheng 
+  - Chuanhong Guo 
+
+description: |
+  This spi controller support single, dual, or quad mode transfer for
+  SPI NOR flash. There should be only one spi slave device following
+  generic spi bindings. It's not recommended to use this controller
+  for devices other than SPI NOR flash due to limited transfer
+  capability of this controller.
+
+allOf:
+  - $ref: /spi/spi-controller.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - mediatek,mt2701-nor
+  - mediatek,mt2712-nor
+  - mediatek,mt7622-nor
+  - mediatek,mt7623-nor
+  - mediatek,mt7629-nor
+  - enum:
+  - mediatek,mt8173-nor
+  - items:
+  - const: mediatek,mt8173-nor
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: clock used for spi bus
+  - description: clock used for controller
+
+  clock-names:
+items:
+  - const: spi
+  - const: sf
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+soc {
+  #address-cells = <2>;
+  #size-cells = <2>;
+
+  nor_flash: spi@1100d000 {
+compatible = "mediatek,mt8173-nor";
+reg = <0 0x1100d000 0 0xe0>;
+interrupts = <&spi_flash_irq>;
+clocks = <&pericfg CLK_PERI_SPI>, <&topckgen CLK_TOP_SPINFI_IFR_SEL>;
+clock-names = "spi", "sf";
+#address-cells = <1>;
+#size-cells = <0>;
+
+flash@0 {
+  compatible = "jedec,spi-nor";
+  reg = <0>;
+};
+  };
+};
+
diff --git a/Documentation/devicetree/bindings/spi/spi-mtk-nor.txt 
b/Documentation/devicetree/bindings/spi/spi-mtk-nor.txt
deleted file mode 100644
index 984ae7fd4f94..
--- a/Documentation/devicetree/bindings/spi/spi-mtk-nor.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Serial NOR flash controller for MediaTek ARM SoCs
-
-Required properties:
-- compatible:For mt8173, compatible should be "mediatek,mt8173-nor",
- and it's the fallback compatible for other Soc.
- For every other SoC, should contain both the SoC-specific 
compatible
- string and "mediatek,mt8173-nor".
- The possible values are:
- "mediatek,mt2701-nor", "mediatek,mt8173-nor"
- "mediatek,mt2712-nor", "mediatek,mt8173-nor"
- "mediatek,mt7622-nor", "mediatek,mt8173-nor"
- "mediatek,mt7623-nor", "mediatek,mt8173-nor"
- "mediatek,mt7629-nor", "mediatek,mt8173-nor"
- "mediatek,mt8173-nor"
-- reg:   physical base address and length of the controller's 
register
-- interrupts:Interrupt number used by the controller.
-- clocks:the phandle of the clocks needed by the nor controller
-- clock-names:   the names of the clocks
- the clocks should be named "spi" and "sf". "spi" is used for 
spi bus,
- and "sf" is used for controller, these are the clocks witch
- hardware needs to enabling nor flash and nor flash controller.
- See 
Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- #address-cells: should be <1>
-- #size-cells:   should be <0>
-
-There should be only one spi slave device following generic spi bindings.
-It's not recommended to use this controller for devices other than SPI NOR
-flash due to limited transfer capability of this controller.
-
-Example:
-
-nor_flash: spi@1100d000 {
-   compatible = "mediatek,mt8173-nor";
-   reg = <0 0x1100d000 0 0xe0>;
-   interrupts = <&spi_flash_irq>;
-   clocks = <&pericfg CLK_PERI_SPI>,
-<&topckgen CLK_TOP_SPIN

Re: WARNING: ODEBUG bug in __do_softirq

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:3a00d3df Add linux-next specific files for 20200825
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15080fa990
kernel config:  https://syzkaller.appspot.com/x/.config?x=9ef0a5f95935d447
dashboard link: https://syzkaller.appspot.com/bug?extid=51c9bdfa559769d2f897
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=17927a2e90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=132b8ede90

The issue was bisected to:

commit 5b317cbf2bcb85a1e96ce87717cb991ecab1dd4d
Author: Rafael J. Wysocki 
Date:   Fri Feb 22 09:17:11 2019 +

Merge branch 'pm-cpufreq-fixes'

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=171ead5d20
final oops: https://syzkaller.appspot.com/x/report.txt?x=149ead5d20
console output: https://syzkaller.appspot.com/x/log.txt?x=109ead5d20

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+51c9bdfa559769d2f...@syzkaller.appspotmail.com
Fixes: 5b317cbf2bcb ("Merge branch 'pm-cpufreq-fixes'")

[ cut here ]
ODEBUG: free active (active state 0) object type: work_struct hint: 
afs_manage_cell+0x0/0x11c0 fs/afs/cell.c:498
WARNING: CPU: 1 PID: 16 at lib/debugobjects.c:485 
debug_print_object+0x160/0x250 lib/debugobjects.c:485
Modules linked in:
CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.9.0-rc2-next-20200825-syzkaller 
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:debug_print_object+0x160/0x250 lib/debugobjects.c:485
Code: dd 60 56 94 88 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 bf 00 00 00 48 8b 
14 dd 60 56 94 88 48 c7 c7 c0 4b 94 88 e8 eb bd a4 fd <0f> 0b 83 05 13 50 1b 07 
01 48 83 c4 20 5b 5d 41 5c 41 5d c3 48 89
RSP: 0018:c9d7fbf8 EFLAGS: 00010086
RAX:  RBX: 0003 RCX: 
RDX: 8880a9686440 RSI: 815da937 RDI: f520001aff71
RBP: 0001 R08: 0001 R09: 8880ae720f8b
R10:  R11: 203a47554245444f R12: 89ba35e0
R13: 814b6290 R14: dead0100 R15: dc00
FS:  () GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f9120aabe78 CR3: 88b2e000 CR4: 001506e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 __debug_check_no_obj_freed lib/debugobjects.c:967 [inline]
 debug_check_no_obj_freed+0x301/0x41c lib/debugobjects.c:998
 kfree+0xf0/0x2c0 mm/slab.c:3755
 rcu_do_batch kernel/rcu/tree.c:2474 [inline]
 rcu_core+0x61e/0x1220 kernel/rcu/tree.c:2709
 __do_softirq+0x2de/0xa24 kernel/softirq.c:298
 run_ksoftirqd kernel/softirq.c:652 [inline]
 run_ksoftirqd+0x89/0x100 kernel/softirq.c:644
 smpboot_thread_fn+0x655/0x9e0 kernel/smpboot.c:165
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294

Re: Re: [PATCH] rtc: sun6i: Fix memleak in sun6i_rtc_clk_init

[dinghao . liu]

> On Sun, Aug 23, 2020 at 3:59 PM Dinghao Liu  wrote:
> >
> > When clk_hw_register_fixed_rate_with_accuracy() fails,
> > clk_data should be freed. It's the same for the subsequent
> > error paths.
> 
> I suppose you should also unregister the already registered clocks
> in the latter two error paths?
> 

Sounds reasonable. But I find that the existing kernel code takes different
strategies for this case. of_sama5d4_sckc_setup() uses clk_hw_unregister() 
after clk_hw_register_fixed_rate_with_accuracy(), while _of_fixed_clk_setup()
uses clk_hw_unregister_fixed_rate(). But at91sam926x_pmc_setup() just does
nothing in this case.

Also, tcon_ch1_setup() uses clk_unregister() after clk_register(), while
clk_register_vco_pll() just does nothing. 

So I'm not sure if we should register here and which unregister function to 
use. Would you please give me more specific advice about this problem?

Regards,
Dinghao

Re: [PATCH] m68k: Correct some typos in comments

[Geert Uytterhoeven]

Hi Finn,

On Thu, Jul 23, 2020 at 1:50 AM Finn Thain  wrote:
> Signed-off-by: Finn Thain 

Thanks for your patch!

> --- a/arch/m68k/kernel/head.S
> +++ b/arch/m68k/kernel/head.S

> @@ -1547,7 +1547,7 @@ func_return   get_bi_record
>   * seven bits of the logical address (LA) are used as an
>   * index into the "root table."  Each entry in the root
>   * table has a bit which specifies if it's a valid pointer to a
> - * pointer table.  Each entry defines a 32KMeg range of memory.
> + * pointer table.  Each entry defines a 32Meg range of memory.
>   * If an entry is invalid then that logical range of 32M is

Ah, lots of opportunities to switch to SI prefixes (MiB) ;-)

>   * invalid and references to that range of memory (when the MMU
>   * is enabled) will fault.  If the entry is valid, then it does

> @@ -2654,7 +2654,7 @@ func_startmmu_get_page_table_entry,%d0/%a1
> jne 2f
>
> /* If the page table entry doesn't exist, we allocate a complete new
> -* page and use it as one continues big page table which can cover
> +* page and use it as one continuous big page table which can cover

Usually I use "contiguous", but the dictionary seems to permit both.

>  * 4MB of memory, nearly almost all mappings have that alignment.
>  */
> get_new_page

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in the m68k for-v5.10 branch.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 3/4] soundwire: SDCA: add helper macro to access controls

[Vinod Koul]

On 25-08-20, 12:16, Pierre-Louis Bossart wrote:
> The upcoming SDCA (SoundWire Device Class Audio) specification defines
> a hierarchical encoding to interface with Class-defined capabilities.
> 
> The specification is not yet accessible to the general public but this
> information is released with explicit permission from the MIPI Board
> to avoid delays with SDCA support on Linux platforms.
> 
> A block of 64 MBytes of register addresses are allocated to SDCA
> controls, starting at address 0x4000. The 26 LSBs which identify
> individual controls are set based on the following variables:
> 
> - Function Number. An SCDA device can be split in up to 8 independent
>   Functions. Each of these Functions is described in the SDCA
>   specification, e.g. Smart Amplifier, Smart Microphone, Simple
>   Microphone, Jack codec, HID, etc.
> 
> - Entity Number.  Within each Function,  an Entity is  an identifiable
>   block.  Up   to  127  Entities   are  connected  in   a  pre-defined
>   graph  (similar to  USB), with  Entity0 reserved  for Function-level
>   configurations.  In  contrast  to  USB, the  SDCA  spec  pre-defines
>   Function Types, topologies, and allowed  options, i.e. the degree of
>   freedom  is not  unlimited to  limit  the possibility  of errors  in
>   descriptors leading to software quirks.
> 
> - Control Selector. Within each Entity, the SDCA specification defines
>   48 controls such as Mute, Gain, AGC, etc, and 16 implementation
>   defined ones. Some Control Selectors might be used for low-level
>   platform setup, and other exposed to applications and users. Note
>   that the same Control Selector capability, e.g. Latency control,
>   might be located at different offsets in different entities, the
>   Control Selector mapping is Entity-specific.
> 
> - Control Number. Some Control Selectors allow channel-specific values
>   to be set, with up to 64 channels allowed. This is mostly used for
>   volume control.
> 
> - Current/Next values. Some Control Selectors are
>   'Dual-Ranked'. Software may either update the Current value directly
>   for immediate effect. Alternatively, software may write into the
>   'Next' values and update the SoundWire 1.2 'Commit Groups' register
>   to copy 'Next' values into 'Current' ones in a synchronized
>   manner. This is different from bank switching which is typically
>   used to change the bus configuration only.
> 
> - MBQ. the Multi-Byte Quantity bit is used to provide atomic updates
>   when accessing more that one byte, for example a 16-bit volume
>   control would be updated consistently, the intermediate values
>   mixing old MSB with new LSB are not applied.
> 
> These 6 parameters are used to build a 32-bit address to access the
> desired Controls. Because of address range, paging is required, but
> the most often used parameter values are placed in the lower 16 bits
> of the address. This helps to keep the paging registers constant while
> updating Controls for a specific Device/Function.
> 
> Reviewed-by: Rander Wang 
> Reviewed-by: Guennadi Liakhovetski 
> Reviewed-by: Kai Vehmanen 
> Signed-off-by: Pierre-Louis Bossart 
> ---
>  include/linux/soundwire/sdw_registers.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/include/linux/soundwire/sdw_registers.h 
> b/include/linux/soundwire/sdw_registers.h
> index 5d3c271af7d1..906dadda7387 100644
> --- a/include/linux/soundwire/sdw_registers.h
> +++ b/include/linux/soundwire/sdw_registers.h
> @@ -305,4 +305,17 @@
>  #define SDW_CASC_PORT_MASK_INTSTAT3  1
>  #define SDW_CASC_PORT_REG_OFFSET_INTSTAT32
>  
> +/* v1.2 device - SDCA address mapping */

Can you please add description of bits used by each field here,
something like we have done for DevId

> +#define SDW_SDCA_CTL(fun, ent, ctl, ch)  (BIT(30) |  
> \
> +  (((fun) & 0x7) << 22) |
> \
> +  (((ent) & 0x40) << 15) |   
> \
> +  (((ent) & 0x3f) << 7) |
> \
> +  (((ctl) & 0x30) << 15) |   
> \
> +  (((ctl) & 0x0f) << 3) |
> \
> +  (((ch) & 0x38) << 12) |
> \
> +  ((ch) & 0x07))

GENMASK() for the bitmaps here please. Also it would look very neat by
using FIELD_PREP() here, you can skip the bit shifts and they would be
done by FIELD_PREP() for you.

> -- 
> 2.25.1

-- 
~Vinod

Re: [PATCH RESEND 04/10] crypto: hisilicon/zip - replace 'sprintf' with 'scnprintf'

[shenyang (M)]

On 2020/8/24 16:29, David Laight wrote:

From: Yang Shen

Sent: 24 August 2020 04:12

Replace 'sprintf' with 'scnprintf' to avoid overrun.

Signed-off-by: Yang Shen 
Reviewed-by: Zhou Wang 
---
 drivers/crypto/hisilicon/zip/zip_main.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/hisilicon/zip/zip_main.c 
b/drivers/crypto/hisilicon/zip/zip_main.c
index df1a16f..1883d1b 100644
--- a/drivers/crypto/hisilicon/zip/zip_main.c
+++ b/drivers/crypto/hisilicon/zip/zip_main.c
@@ -428,7 +428,7 @@ static ssize_t hisi_zip_ctrl_debug_read(struct file *filp, 
char __user *buf,
return -EINVAL;
}
spin_unlock_irq(&file->lock);
-   ret = sprintf(tbuf, "%u\n", val);
+   ret = scnprintf(tbuf, HZIP_BUF_SIZE, "%u\n", val);


Should that be sizeof (tbuf).


return simple_read_from_buffer(buf, count, pos, tbuf, ret);
 }

@@ -514,13 +514,16 @@ static int hisi_zip_core_debug_init(struct hisi_qm *qm)
struct debugfs_regset32 *regset;
struct dentry *tmp_d;
char buf[HZIP_BUF_SIZE];
-   int i;
+   int i, ret;

for (i = 0; i < HZIP_CORE_NUM; i++) {
if (i < HZIP_COMP_CORE_NUM)
-   sprintf(buf, "comp_core%d", i);
+   ret = scnprintf(buf, HZIP_BUF_SIZE, "comp_core%d", i);
else
-   sprintf(buf, "decomp_core%d", i - HZIP_COMP_CORE_NUM);
+   ret = scnprintf(buf, HZIP_BUF_SIZE, "decomp_core%d",
+   i - HZIP_COMP_CORE_NUM);
+   if (!ret)
+   return -ENOMEM;


and that is just so wrong - did you even try to test
the 'buffer too small' code path?

David



Do you means the check is unnecessary?

Yang

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)


.

[RESEND PATCH v4] iommu/mediatek: check 4GB mode by reading infracfg

[Miles Chen]

In previous discussion [1] and [2], we found that it is risky to
use max_pfn or totalram_pages to tell if 4GB mode is enabled.

Check 4GB mode by reading infracfg register, remove the usage
of the un-exported symbol max_pfn.

This is a step towards building mtk_iommu as a kernel module.

[1] https://lore.kernel.org/lkml/20200603161132.2441-1-miles.c...@mediatek.com/
[2] https://lore.kernel.org/lkml/20200604080120.2628-1-miles.c...@mediatek.com/
[3] https://lore.kernel.org/lkml/20200715205120.GA778876@bogus/

Cc: Mike Rapoport 
Cc: David Hildenbrand 
Cc: Yong Wu 
Cc: Yingjoe Chen 
Cc: Christoph Hellwig 
Cc: Rob Herring 
Cc: Matthias Brugger 
Signed-off-by: Miles Chen 

---

Change since v3
- use lore.kernel.org links
- move "change since..." after "---"

Change since v2:
- determine compatible string by m4u_plat
- rebase to next-20200720
- add "---"

Change since v1:
- remove the phandle usage, search for infracfg instead [3]
- use infracfg instead of infracfg_regmap
- move infracfg definitaions to linux/soc/mediatek/infracfg.h
- update enable_4GB only when has_4gb_mode
---
 drivers/iommu/mtk_iommu.c | 34 +++
 include/linux/soc/mediatek/infracfg.h |  3 +++
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index 785b228d39a6..adc350150492 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -3,7 +3,6 @@
  * Copyright (c) 2015-2016 MediaTek Inc.
  * Author: Yong Wu 
  */
-#include 
 #include 
 #include 
 #include 
@@ -15,13 +14,16 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -640,8 +642,11 @@ static int mtk_iommu_probe(struct platform_device *pdev)
struct resource *res;
resource_size_t ioaddr;
struct component_match  *match = NULL;
+   struct regmap   *infracfg;
void*protect;
int i, larb_nr, ret;
+   u32 val;
+   char*p;
 
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -655,10 +660,29 @@ static int mtk_iommu_probe(struct platform_device *pdev)
return -ENOMEM;
data->protect_base = ALIGN(virt_to_phys(protect), MTK_PROTECT_PA_ALIGN);
 
-   /* Whether the current dram is over 4GB */
-   data->enable_4GB = !!(max_pfn > (BIT_ULL(32) >> PAGE_SHIFT));
-   if (!MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE))
-   data->enable_4GB = false;
+   data->enable_4GB = false;
+   if (MTK_IOMMU_HAS_FLAG(data->plat_data, HAS_4GB_MODE)) {
+   switch (data->plat_data->m4u_plat) {
+   case M4U_MT2712:
+   p = "mediatek,mt2712-infracfg";
+   break;
+   case M4U_MT8173:
+   p = "mediatek,mt8173-infracfg";
+   break;
+   default:
+   p = NULL;
+   }
+
+   infracfg = syscon_regmap_lookup_by_compatible(p);
+
+   if (IS_ERR(infracfg))
+   return PTR_ERR(infracfg);
+
+   ret = regmap_read(infracfg, REG_INFRA_MISC, &val);
+   if (ret)
+   return ret;
+   data->enable_4GB = !!(val & F_DDR_4GB_SUPPORT_EN);
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(dev, res);
diff --git a/include/linux/soc/mediatek/infracfg.h 
b/include/linux/soc/mediatek/infracfg.h
index fd25f0148566..233463d789c6 100644
--- a/include/linux/soc/mediatek/infracfg.h
+++ b/include/linux/soc/mediatek/infracfg.h
@@ -32,6 +32,9 @@
 #define MT7622_TOP_AXI_PROT_EN_WB  (BIT(2) | BIT(6) | \
 BIT(7) | BIT(8))
 
+#define REG_INFRA_MISC 0xf00
+#define F_DDR_4GB_SUPPORT_EN   BIT(13)
+
 int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
bool reg_update);
 int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
-- 
2.18.0

Re: [PATCH] media: mx2_emmaprp: Fix memleak in emmaprp_probe

[Hans Verkuil]

On 25/08/2020 11:39, Dinghao Liu wrote:
> When platform_get_irq() fails, we should release
> vfd and unregister pcdev->v4l2_dev just like the
> subsequent error paths.
> 
> Fixes: d4e192cc44914 ("media: mx2_emmaprp: Check for platform_get_irq() 
> error")
> Signed-off-by: Dinghao Liu 
> ---
>  drivers/media/platform/mx2_emmaprp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/mx2_emmaprp.c 
> b/drivers/media/platform/mx2_emmaprp.c
> index df78df59da45..2fd31ed86005 100644
> --- a/drivers/media/platform/mx2_emmaprp.c
> +++ b/drivers/media/platform/mx2_emmaprp.c
> @@ -853,7 +853,7 @@ static int emmaprp_probe(struct platform_device *pdev)
>  
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0)
> - return irq;
> + goto rel_vdev;

You need to add 'ret = irq;' here, otherwise the platform_get_irq error code
is not correctly propagated.

Looks good otherwise.

Regards,

Hans

>   ret = devm_request_irq(&pdev->dev, irq, emmaprp_irq, 0,
>  dev_name(&pdev->dev), pcdev);
>   if (ret)
>