All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2] hwmon: (iio_hwmon) Use devm functions
From: Guenter Roeck @ 2018-07-23 18:42 UTC (permalink / raw)
  To: Maxime Roussin-Bélanger; +Cc: Jean Delvare, linux-hwmon, Jonathan Cameron
In-Reply-To: <20180723033329.28213-1-maxime.roussinbelanger@gmail.com>

On Sun, Jul 22, 2018 at 11:33:29PM -0400, Maxime Roussin-Bélanger wrote:
> Use devm_iio_channel_get_all() to automatically release
> channels.
> 
> Use devm_hwmon_device_register_with_groups() to
> automatically unregister the device.
> 
> Signed-off-by: Maxime Roussin-Bélanger <maxime.roussinbelanger@gmail.com>

Applied, with a couple of additional changes (see below).

Thanks,
Guenter

> ---
> Changes in v2:
> 	- Remove unnecessary {}
> 
> drivers/hwmon/iio_hwmon.c | 63 ++++++++++++---------------------------
>  1 file changed, 19 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
> index a3a1d1cb2f27..44d7dfe9cb46 100644
> --- a/drivers/hwmon/iio_hwmon.c
> +++ b/drivers/hwmon/iio_hwmon.c
> @@ -73,44 +73,38 @@ static int iio_hwmon_probe(struct platform_device *pdev)
>  	if (dev->of_node && dev->of_node->name)
>  		name = dev->of_node->name;
>  
> -	channels = iio_channel_get_all(dev);
> +	channels = devm_iio_channel_get_all(dev);
>  	if (IS_ERR(channels)) {
>  		if (PTR_ERR(channels) == -ENODEV)
>  			return -EPROBE_DEFER;
>  		return PTR_ERR(channels);
>  	}
>  
>  	st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> -	if (st == NULL) {
> -		ret = -ENOMEM;
> -		goto error_release_channels;
> -	}
> +	if (st == NULL)
> +		return -ENOMEM;
>  
>  	st->channels = channels;
>  
>  	/* count how many attributes we have */
>  	while (st->channels[st->num_channels].indio_dev)
>  		st->num_channels++;
>  
>  	st->attrs = devm_kzalloc(dev,
>  				 sizeof(*st->attrs) * (st->num_channels + 1),
>  				 GFP_KERNEL);
> -	if (st->attrs == NULL) {
> -		ret = -ENOMEM;
> -		goto error_release_channels;
> -	}
> +	if (st->attrs == NULL)
> +		return -ENOMEM;
>  
>  	for (i = 0; i < st->num_channels; i++) {
>  		a = devm_kzalloc(dev, sizeof(*a), GFP_KERNEL);
> -		if (a == NULL) {
> -			ret = -ENOMEM;
> -			goto error_release_channels;
> -		}
> +		if (a == NULL)
> +			return -ENOMEM;
>  
>  		sysfs_attr_init(&a->dev_attr.attr);
>  		ret = iio_get_channel_type(&st->channels[i], &type);
>  		if (ret < 0)
> -			goto error_release_channels;
> +			return ret;
>  
>  		switch (type) {
>  		case IIO_VOLTAGE:
> @@ -138,49 +132,31 @@ static int iio_hwmon_probe(struct platform_device *pdev)
>  							       humidity_i++);
>  			break;
>  		default:
> -			ret = -EINVAL;
> -			goto error_release_channels;
> -		}
> -		if (a->dev_attr.attr.name == NULL) {
> -			ret = -ENOMEM;
> -			goto error_release_channels;
> +			return -EINVAL;
>  		}
> +		if (a->dev_attr.attr.name == NULL)
> +			return -ENOMEM;
> +
>  		a->dev_attr.show = iio_hwmon_read_val;
>  		a->dev_attr.attr.mode = S_IRUGO;
>  		a->index = i;
>  		st->attrs[i] = &a->dev_attr.attr;
>  	}
>  
>  	st->attr_group.attrs = st->attrs;
>  	st->groups[0] = &st->attr_group;
>  
>  	sname = devm_kstrdup(dev, name, GFP_KERNEL);
> -	if (!sname) {
> -		ret = -ENOMEM;
> -		goto error_release_channels;
> -	}
> +	if (!sname)
> +		return -ENOMEM;
>  
>  	strreplace(sname, '-', '_');
> -	st->hwmon_dev = hwmon_device_register_with_groups(dev, sname, st,
> -							  st->groups);
> -	if (IS_ERR(st->hwmon_dev)) {
> -		ret = PTR_ERR(st->hwmon_dev);
> -		goto error_release_channels;
> -	}
> -	platform_set_drvdata(pdev, st);
> -	return 0;
> -
> -error_release_channels:
> -	iio_channel_release_all(channels);
> -	return ret;
> -}
> +	st->hwmon_dev = devm_hwmon_device_register_with_groups(dev, sname, st,
> +							       st->groups);

st->hwmon_dev is now unnecessary. Changed to local variable.

> +	if (IS_ERR(st->hwmon_dev))
> +		return PTR_ERR(st->hwmon_dev);
>  
> -static int iio_hwmon_remove(struct platform_device *pdev)
> -{
> -	struct iio_hwmon_state *st = platform_get_drvdata(pdev);
> -
> -	hwmon_device_unregister(st->hwmon_dev);
> -	iio_channel_release_all(st->channels);
> +	platform_set_drvdata(pdev, st);

This is now unnecessary. Dropped. With this, the simplified the code to

	hwmon_dev = devm_hwmon_device_register_with_groups(dev, sname, st,
							   st->groups);
	return PTR_ERR_OR_ZERO(hwmon_dev);

>  
>  	return 0;
>  }
> @@ -197,7 +173,6 @@ static struct platform_driver __refdata iio_hwmon_driver = {
>  		.of_match_table = iio_hwmon_of_match,
>  	},
>  	.probe = iio_hwmon_probe,
> -	.remove = iio_hwmon_remove,
>  };
>  
>  module_platform_driver(iio_hwmon_driver);

^ permalink raw reply

* Re: [Xenomai] Cobalt Scheduling tasks on a single core
From: Jackson Jones @ 2018-07-23 19:44 UTC (permalink / raw)
  To: xenomai, Philippe Gerum
In-Reply-To: <b16ed60f-31f2-3ef0-f7bc-a35de9629b51@xenomai.org>

We were using processor affinity and assigning the RT tasks to different
cores. The issue we ran into is that the application would lock up (causing
the whole system to freeze) after several hours of being idle
(approximately 8 hours). When we did not use processor affinity, our app
would not lock up (but then all RT task are on one core).

One thing I noticed is that currently we are designating all the CPUs to be
real time (passing xenomai.supported_cpus=0x0000000f). Could this be the
cause of the lockup? Should we leave one cpu out (of the real time group)?

We also discovered over this past weekend that if we enable these options
in the Linux kernel, our app does not lock up:

CONFIG_LOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0

These options are not something we want to ship with, but it is interesting
that they seem to prevent the lockup.




On Sat, Jul 21, 2018 at 1:47 AM, Philippe Gerum <rpm@xenomai.org> wrote:

> On 07/21/2018 01:28 AM, Jackson Jones wrote:
> > We are running against xenomai 3.0.7 on a quad core arm (i.mx6).  Xenomai
> > was configured with these arguments:
> >
> > #export CFLAGS=-O2 LIBS=-lposix
> > ./configure \
> >     --with-core=cobalt \
> >     --enable-smp \
> >     --enable-registry \
> >     --enable-pshared \
> >     --enable-dlopen-libs \
> >     --enable-sanity \
> >     --disable-tls \
> >     --enable-valgrind-client \
> >     --disable-assert
> >
> > The main app spawns off several real time tasks. Cobalt is scheduling all
> > the real-time tasks on one core. Is this normal behavior for Cobalt? I
> > would expect it to take advantage of the multiple cores.
>
> Your application has to decide for this, CPU migration is costly in many
> ways, increases latency. For this reason, no Xenomai co-kernel ever has
> implemented any load balancing of any sort. On the contrary, it does pin
> each emerging thread to its current CPU precisely to prevent unexpected
> migration while the threads runs in secondary mode, before entering the
> rt processing loop - this CPU may of course be changed by the
> application afterwards.
>
> What you are seeing here is the default assignment of threads to CPUs:
> the regular kernel picked a base CPU for each newly created thread, then
> Cobalt pinned it there.
>
> The idea is to figure out the best placement of the rt threads among the
> CPUs available for rt processing, moving them accordingly using
> sched_setaffinity() during the init phase. This placement could be
> paired with setting xenomai.supported_cpus for restricting the CPUs
> dedicated to real-time duties to a subset of the available cores.
>
> --
> Philippe.
>

^ permalink raw reply

* arch/arc/ allmodconfig
From: Randy Dunlap @ 2018-07-23 19:45 UTC (permalink / raw)
  To: linux-snps-arc
In-Reply-To: <DB6PR05MB4597A63819F227B17652B5B2B2560@DB6PR05MB4597.eurprd05.prod.outlook.com>

On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> Hi Vineet, randy
> 
> Indeed this structure is missing, following is a patch based on linux-4.17.9.
> Sorry about that.
> 
> Thanks
> 
> 
> diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h    2018-07-22 16:16:09.000000000 +0300
> +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h        2018-07-23 11:18:12.179402620 +0300
> @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
>  };
>  
>  /* AUX registers definition */
> +struct nps_host_reg_aux_dpc {
> +       union {
> +               struct {
> +                       u32 ien:1, men:1, hen:1, reserved:29;
> +               };
> +               u32 value;
> +       };
> +};
> +
>  struct nps_host_reg_aux_udmc {
>         union {
>                 struct {
> 

Thanks, this fixes the build error.

I will not that outlook is not the best email client that you could use for
sending Linux patches.  I don't know if you generated the patch with spaces
or tabs being used for indentation, but above, it contains all leading spaces
for indentation, which is Not Good.


-- 
~Randy

^ permalink raw reply

* [Qemu-devel] [PULL 0/1] Build fix for -rc2
From: Eduardo Habkost @ 2018-07-23 19:45 UTC (permalink / raw)
  To: Peter Maydell, qemu-devel
  Cc: Paolo Bonzini, Eduardo Habkost, Marcel Apfelbaum,
	Michael S. Tsirkin, Richard Henderson

The following changes since commit 9ba7dd14355bb7957680d5ef764471ab102df099:

  Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2018-07-23' into staging (2018-07-23 15:15:46 +0100)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/x86-next-pull-request

for you to fetch changes up to 5f00335aecafc9ad56592d943619d3252f8941f1:

  i386: Rename enum CacheType members (2018-07-23 12:56:19 -0300)

----------------------------------------------------------------
Fix for -rc2

* Fix build failure on mips host

----------------------------------------------------------------

Eduardo Habkost (1):
  i386: Rename enum CacheType members

 target/i386/cpu.h |   4 +-
 target/i386/cpu.c | 128 +++++++++++++++++++++++-----------------------
 2 files changed, 66 insertions(+), 66 deletions(-)

-- 
2.18.0.rc1.1.g3f1ff2140

^ permalink raw reply

* Re: arch/arc/ allmodconfig
From: Randy Dunlap @ 2018-07-23 19:45 UTC (permalink / raw)
  To: Ofer Levi(SW), Vineet Gupta, LKML,
	linux-snps-arc@lists.infradead.org
  Cc: Leon Romanovsky, Meir Lichtinger
In-Reply-To: <DB6PR05MB4597A63819F227B17652B5B2B2560@DB6PR05MB4597.eurprd05.prod.outlook.com>

On 07/23/2018 01:34 AM, Ofer Levi(SW) wrote:
> Hi Vineet, randy
> 
> Indeed this structure is missing, following is a patch based on linux-4.17.9.
> Sorry about that.
> 
> Thanks
> 
> 
> diff -uprN linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h
> --- linux-4.17.9.org/arch/arc/plat-eznps/include/plat/ctop.h    2018-07-22 16:16:09.000000000 +0300
> +++ linux-4.17.9/arch/arc/plat-eznps/include/plat/ctop.h        2018-07-23 11:18:12.179402620 +0300
> @@ -143,6 +143,15 @@ struct nps_host_reg_gim_p_int_dst {
>  };
>  
>  /* AUX registers definition */
> +struct nps_host_reg_aux_dpc {
> +       union {
> +               struct {
> +                       u32 ien:1, men:1, hen:1, reserved:29;
> +               };
> +               u32 value;
> +       };
> +};
> +
>  struct nps_host_reg_aux_udmc {
>         union {
>                 struct {
> 

Thanks, this fixes the build error.

I will not that outlook is not the best email client that you could use for
sending Linux patches.  I don't know if you generated the patch with spaces
or tabs being used for indentation, but above, it contains all leading spaces
for indentation, which is Not Good.


-- 
~Randy

^ permalink raw reply

* [Qemu-devel] [PULL 1/1] i386: Rename enum CacheType members
From: Eduardo Habkost @ 2018-07-23 19:45 UTC (permalink / raw)
  To: Peter Maydell, qemu-devel
  Cc: Paolo Bonzini, Eduardo Habkost, Marcel Apfelbaum,
	Michael S. Tsirkin, Richard Henderson
In-Reply-To: <20180723194521.26831-1-ehabkost@redhat.com>

Rename DCACHE to DATA_CACHE and ICACHE to INSTRUCTION_CACHE.
This avoids conflict with Linux asm/cachectl.h macros and fixes
build failure on mips hosts.

Reported-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20180717194010.30096-1-ehabkost@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Acked-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Reviewed-by: Babu Moger <babu.moger@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
---
 target/i386/cpu.h |   4 +-
 target/i386/cpu.c | 128 +++++++++++++++++++++++-----------------------
 2 files changed, 66 insertions(+), 66 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 2c5a0d90a6..194e2e6b92 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1050,8 +1050,8 @@ typedef enum TPRAccess {
 /* Cache information data structures: */
 
 enum CacheType {
-    DCACHE,
-    ICACHE,
+    DATA_CACHE,
+    INSTRUCTION_CACHE,
     UNIFIED_CACHE
 };
 
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index e0e2f2eea1..f454d4beb3 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -71,123 +71,123 @@ struct CPUID2CacheDescriptorInfo {
  * From Intel SDM Volume 2A, CPUID instruction
  */
 struct CPUID2CacheDescriptorInfo cpuid2_cache_descriptors[] = {
-    [0x06] = { .level = 1, .type = ICACHE,        .size =   8 * KiB,
+    [0x06] = { .level = 1, .type = INSTRUCTION_CACHE, .size =   8 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x08] = { .level = 1, .type = ICACHE,        .size =  16 * KiB,
+    [0x08] = { .level = 1, .type = INSTRUCTION_CACHE, .size =  16 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x09] = { .level = 1, .type = ICACHE,        .size =  32 * KiB,
+    [0x09] = { .level = 1, .type = INSTRUCTION_CACHE, .size =  32 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x0A] = { .level = 1, .type = DCACHE,        .size =   8 * KiB,
+    [0x0A] = { .level = 1, .type = DATA_CACHE,        .size =   8 * KiB,
                .associativity = 2,  .line_size = 32, },
-    [0x0C] = { .level = 1, .type = DCACHE,        .size =  16 * KiB,
+    [0x0C] = { .level = 1, .type = DATA_CACHE,        .size =  16 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x0D] = { .level = 1, .type = DCACHE,        .size =  16 * KiB,
+    [0x0D] = { .level = 1, .type = DATA_CACHE,        .size =  16 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x0E] = { .level = 1, .type = DCACHE,        .size =  24 * KiB,
+    [0x0E] = { .level = 1, .type = DATA_CACHE,        .size =  24 * KiB,
                .associativity = 6,  .line_size = 64, },
-    [0x1D] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+    [0x1D] = { .level = 2, .type = UNIFIED_CACHE,     .size = 128 * KiB,
                .associativity = 2,  .line_size = 64, },
-    [0x21] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+    [0x21] = { .level = 2, .type = UNIFIED_CACHE,     .size = 256 * KiB,
                .associativity = 8,  .line_size = 64, },
     /* lines per sector is not supported cpuid2_cache_descriptor(),
     * so descriptors 0x22, 0x23 are not included
     */
-    [0x24] = { .level = 2, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0x24] = { .level = 2, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 16, .line_size = 64, },
     /* lines per sector is not supported cpuid2_cache_descriptor(),
     * so descriptors 0x25, 0x20 are not included
     */
-    [0x2C] = { .level = 1, .type = DCACHE,        .size =  32 * KiB,
+    [0x2C] = { .level = 1, .type = DATA_CACHE,        .size =  32 * KiB,
                .associativity = 8,  .line_size = 64, },
-    [0x30] = { .level = 1, .type = ICACHE,        .size =  32 * KiB,
+    [0x30] = { .level = 1, .type = INSTRUCTION_CACHE, .size =  32 * KiB,
                .associativity = 8,  .line_size = 64, },
-    [0x41] = { .level = 2, .type = UNIFIED_CACHE, .size = 128 * KiB,
+    [0x41] = { .level = 2, .type = UNIFIED_CACHE,     .size = 128 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x42] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+    [0x42] = { .level = 2, .type = UNIFIED_CACHE,     .size = 256 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x43] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0x43] = { .level = 2, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 4,  .line_size = 32, },
-    [0x44] = { .level = 2, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0x44] = { .level = 2, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 4,  .line_size = 32, },
-    [0x45] = { .level = 2, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0x45] = { .level = 2, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 4,  .line_size = 32, },
-    [0x46] = { .level = 3, .type = UNIFIED_CACHE, .size =   4 * MiB,
+    [0x46] = { .level = 3, .type = UNIFIED_CACHE,     .size =   4 * MiB,
                .associativity = 4,  .line_size = 64, },
-    [0x47] = { .level = 3, .type = UNIFIED_CACHE, .size =   8 * MiB,
+    [0x47] = { .level = 3, .type = UNIFIED_CACHE,     .size =   8 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0x48] = { .level = 2, .type = UNIFIED_CACHE, .size =   3 * MiB,
+    [0x48] = { .level = 2, .type = UNIFIED_CACHE,     .size =   3 * MiB,
                .associativity = 12, .line_size = 64, },
     /* Descriptor 0x49 depends on CPU family/model, so it is not included */
-    [0x4A] = { .level = 3, .type = UNIFIED_CACHE, .size =   6 * MiB,
+    [0x4A] = { .level = 3, .type = UNIFIED_CACHE,     .size =   6 * MiB,
                .associativity = 12, .line_size = 64, },
-    [0x4B] = { .level = 3, .type = UNIFIED_CACHE, .size =   8 * MiB,
+    [0x4B] = { .level = 3, .type = UNIFIED_CACHE,     .size =   8 * MiB,
                .associativity = 16, .line_size = 64, },
-    [0x4C] = { .level = 3, .type = UNIFIED_CACHE, .size =  12 * MiB,
+    [0x4C] = { .level = 3, .type = UNIFIED_CACHE,     .size =  12 * MiB,
                .associativity = 12, .line_size = 64, },
-    [0x4D] = { .level = 3, .type = UNIFIED_CACHE, .size =  16 * MiB,
+    [0x4D] = { .level = 3, .type = UNIFIED_CACHE,     .size =  16 * MiB,
                .associativity = 16, .line_size = 64, },
-    [0x4E] = { .level = 2, .type = UNIFIED_CACHE, .size =   6 * MiB,
+    [0x4E] = { .level = 2, .type = UNIFIED_CACHE,     .size =   6 * MiB,
                .associativity = 24, .line_size = 64, },
-    [0x60] = { .level = 1, .type = DCACHE,        .size =  16 * KiB,
+    [0x60] = { .level = 1, .type = DATA_CACHE,        .size =  16 * KiB,
                .associativity = 8,  .line_size = 64, },
-    [0x66] = { .level = 1, .type = DCACHE,        .size =   8 * KiB,
+    [0x66] = { .level = 1, .type = DATA_CACHE,        .size =   8 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x67] = { .level = 1, .type = DCACHE,        .size =  16 * KiB,
+    [0x67] = { .level = 1, .type = DATA_CACHE,        .size =  16 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x68] = { .level = 1, .type = DCACHE,        .size =  32 * KiB,
+    [0x68] = { .level = 1, .type = DATA_CACHE,        .size =  32 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x78] = { .level = 2, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0x78] = { .level = 2, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 4,  .line_size = 64, },
     /* lines per sector is not supported cpuid2_cache_descriptor(),
     * so descriptors 0x79, 0x7A, 0x7B, 0x7C are not included.
     */
-    [0x7D] = { .level = 2, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0x7D] = { .level = 2, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0x7F] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0x7F] = { .level = 2, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 2,  .line_size = 64, },
-    [0x80] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0x80] = { .level = 2, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 8,  .line_size = 64, },
-    [0x82] = { .level = 2, .type = UNIFIED_CACHE, .size = 256 * KiB,
+    [0x82] = { .level = 2, .type = UNIFIED_CACHE,     .size = 256 * KiB,
                .associativity = 8,  .line_size = 32, },
-    [0x83] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0x83] = { .level = 2, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 8,  .line_size = 32, },
-    [0x84] = { .level = 2, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0x84] = { .level = 2, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 8,  .line_size = 32, },
-    [0x85] = { .level = 2, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0x85] = { .level = 2, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 8,  .line_size = 32, },
-    [0x86] = { .level = 2, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0x86] = { .level = 2, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0x87] = { .level = 2, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0x87] = { .level = 2, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0xD0] = { .level = 3, .type = UNIFIED_CACHE, .size = 512 * KiB,
+    [0xD0] = { .level = 3, .type = UNIFIED_CACHE,     .size = 512 * KiB,
                .associativity = 4,  .line_size = 64, },
-    [0xD1] = { .level = 3, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0xD1] = { .level = 3, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 4,  .line_size = 64, },
-    [0xD2] = { .level = 3, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0xD2] = { .level = 3, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 4,  .line_size = 64, },
-    [0xD6] = { .level = 3, .type = UNIFIED_CACHE, .size =   1 * MiB,
+    [0xD6] = { .level = 3, .type = UNIFIED_CACHE,     .size =   1 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0xD7] = { .level = 3, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0xD7] = { .level = 3, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0xD8] = { .level = 3, .type = UNIFIED_CACHE, .size =   4 * MiB,
+    [0xD8] = { .level = 3, .type = UNIFIED_CACHE,     .size =   4 * MiB,
                .associativity = 8,  .line_size = 64, },
-    [0xDC] = { .level = 3, .type = UNIFIED_CACHE, .size = 1.5 * MiB,
+    [0xDC] = { .level = 3, .type = UNIFIED_CACHE,     .size = 1.5 * MiB,
                .associativity = 12, .line_size = 64, },
-    [0xDD] = { .level = 3, .type = UNIFIED_CACHE, .size =   3 * MiB,
+    [0xDD] = { .level = 3, .type = UNIFIED_CACHE,     .size =   3 * MiB,
                .associativity = 12, .line_size = 64, },
-    [0xDE] = { .level = 3, .type = UNIFIED_CACHE, .size =   6 * MiB,
+    [0xDE] = { .level = 3, .type = UNIFIED_CACHE,     .size =   6 * MiB,
                .associativity = 12, .line_size = 64, },
-    [0xE2] = { .level = 3, .type = UNIFIED_CACHE, .size =   2 * MiB,
+    [0xE2] = { .level = 3, .type = UNIFIED_CACHE,     .size =   2 * MiB,
                .associativity = 16, .line_size = 64, },
-    [0xE3] = { .level = 3, .type = UNIFIED_CACHE, .size =   4 * MiB,
+    [0xE3] = { .level = 3, .type = UNIFIED_CACHE,     .size =   4 * MiB,
                .associativity = 16, .line_size = 64, },
-    [0xE4] = { .level = 3, .type = UNIFIED_CACHE, .size =   8 * MiB,
+    [0xE4] = { .level = 3, .type = UNIFIED_CACHE,     .size =   8 * MiB,
                .associativity = 16, .line_size = 64, },
-    [0xEA] = { .level = 3, .type = UNIFIED_CACHE, .size =  12 * MiB,
+    [0xEA] = { .level = 3, .type = UNIFIED_CACHE,     .size =  12 * MiB,
                .associativity = 24, .line_size = 64, },
-    [0xEB] = { .level = 3, .type = UNIFIED_CACHE, .size =  18 * MiB,
+    [0xEB] = { .level = 3, .type = UNIFIED_CACHE,     .size =  18 * MiB,
                .associativity = 24, .line_size = 64, },
-    [0xEC] = { .level = 3, .type = UNIFIED_CACHE, .size =  24 * MiB,
+    [0xEC] = { .level = 3, .type = UNIFIED_CACHE,     .size =  24 * MiB,
                .associativity = 24, .line_size = 64, },
 };
 
@@ -238,10 +238,10 @@ static uint8_t cpuid2_cache_descriptor(CPUCacheInfo *cache)
 #define CACHE_COMPLEX_IDX     (1 << 2)
 
 /* Encode CacheType for CPUID[4].EAX */
-#define CACHE_TYPE(t) (((t) == DCACHE)  ? CACHE_TYPE_D  : \
-                         ((t) == ICACHE)  ? CACHE_TYPE_I  : \
-                         ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
-                         0 /* Invalid value */)
+#define CACHE_TYPE(t) (((t) == DATA_CACHE) ? CACHE_TYPE_D : \
+                       ((t) == INSTRUCTION_CACHE) ? CACHE_TYPE_I : \
+                       ((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
+                       0 /* Invalid value */)
 
 
 /* Encode cache info for CPUID[4] */
@@ -538,7 +538,7 @@ static void encode_topo_cpuid8000001e(CPUState *cs, X86CPU *cpu,
 
 /* L1 data cache: */
 static CPUCacheInfo legacy_l1d_cache = {
-    .type = DCACHE,
+    .type = DATA_CACHE,
     .level = 1,
     .size = 32 * KiB,
     .self_init = 1,
@@ -551,7 +551,7 @@ static CPUCacheInfo legacy_l1d_cache = {
 
 /*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
 static CPUCacheInfo legacy_l1d_cache_amd = {
-    .type = DCACHE,
+    .type = DATA_CACHE,
     .level = 1,
     .size = 64 * KiB,
     .self_init = 1,
@@ -565,7 +565,7 @@ static CPUCacheInfo legacy_l1d_cache_amd = {
 
 /* L1 instruction cache: */
 static CPUCacheInfo legacy_l1i_cache = {
-    .type = ICACHE,
+    .type = INSTRUCTION_CACHE,
     .level = 1,
     .size = 32 * KiB,
     .self_init = 1,
@@ -578,7 +578,7 @@ static CPUCacheInfo legacy_l1i_cache = {
 
 /*FIXME: CPUID leaf 0x80000005 is inconsistent with leaves 2 & 4 */
 static CPUCacheInfo legacy_l1i_cache_amd = {
-    .type = ICACHE,
+    .type = INSTRUCTION_CACHE,
     .level = 1,
     .size = 64 * KiB,
     .self_init = 1,
@@ -1310,7 +1310,7 @@ struct X86CPUDefinition {
 
 static CPUCaches epyc_cache_info = {
     .l1d_cache = &(CPUCacheInfo) {
-        .type = DCACHE,
+        .type = DATA_CACHE,
         .level = 1,
         .size = 32 * KiB,
         .line_size = 64,
@@ -1322,7 +1322,7 @@ static CPUCaches epyc_cache_info = {
         .no_invd_sharing = true,
     },
     .l1i_cache = &(CPUCacheInfo) {
-        .type = ICACHE,
+        .type = INSTRUCTION_CACHE,
         .level = 1,
         .size = 64 * KiB,
         .line_size = 64,
-- 
2.18.0.rc1.1.g3f1ff2140

^ permalink raw reply related

* Re: rte_mbuf library likely()/unlikely()
From: Stephen Hemminger @ 2018-07-23 19:45 UTC (permalink / raw)
  To: Morten Brørup; +Cc: Olivier Matz, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35B421F0@smartserver.smartshare.dk>

On Mon, 23 Jul 2018 20:59:29 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Monday, July 23, 2018 7:38 PM
> > To: Morten Brørup
> > Cc: Olivier Matz; dev@dpdk.org
> > Subject: Re: [dpdk-dev] rte_mbuf library likely()/unlikely()
> > 
> > On Mon, 23 Jul 2018 15:53:42 +0200
> > Morten Brørup <mb@smartsharesystems.com> wrote:
> >   
> > > Hi Olivier,
> > >
> > >
> > >
> > > I noticed that __rte_pktmbuf_read() could do with an unlikely(), so I  
> > went through the entire library. Here are my suggested modifications.  
> > >
> > >
> > >
> > >
> > >
> > > diff -bu rte_mbuf.c.orig rte_mbuf.c
> > >
> > > --- rte_mbuf.c.orig     2018-07-23 15:13:22.000000000 +0200
> > >
> > > +++ rte_mbuf.c  2018-07-23 15:32:53.000000000 +0200
> > >
> > > @@ -173,19 +173,19 @@
> > >
> > > {
> > >
> > >         unsigned int nb_segs, pkt_len;
> > >
> > >
> > >
> > > -       if (m == NULL)
> > >
> > > +       if (unlikely(m == NULL))
> > >
> > >                 rte_panic("mbuf is NULL\n");
> > >
> > >  
> > 
> > Adding is unlikely is not necessary since rte_panic is marked with cold
> > attribute
> > which has the same effect.  
> 
> I was not aware of this. Although it is not visible from the source code files using rte_panic(), it probably means we shouldn't as so much as I thought. Here's an updated patch for rte_mbuf.c, where it is relevant. The other two suggested patches are unaffected.
> 
> diff -bu rte_mbuf.c.orig rte_mbuf.c
> --- rte_mbuf.c.orig     2018-07-23 15:13:22.000000000 +0200
> +++ rte_mbuf.c  2018-07-23 20:52:35.000000000 +0200
> @@ -249,7 +249,7 @@
>         const struct rte_mbuf *seg = m;
>         uint32_t buf_off = 0, copy_len;
> 
> -       if (off + len > rte_pktmbuf_pkt_len(m))
> +       if (unlikely(off + len > rte_pktmbuf_pkt_len(m)))
>                 return NULL;
> 
>         while (off >= rte_pktmbuf_data_len(seg)) {
> @@ -257,7 +257,7 @@
>                 seg = seg->next;
>         }
> 
> -       if (off + len <= rte_pktmbuf_data_len(seg))
> +       if (likely(off + len <= rte_pktmbuf_data_len(seg)))
>                 return rte_pktmbuf_mtod_offset(seg, char *, off);
> 
>         /* rare case: header is split among several segments */
> @@ -344,7 +344,7 @@
>         unsigned int i;
>         int ret;
> 
> -       if (buflen == 0)
> +       if (unlikely(buflen == 0))
>                 return -1;
> 
>         buf[0] = '\0';
> @@ -355,9 +355,9 @@
>                 if (name == NULL)
>                         name = rx_flags[i].default_name;
>                 ret = snprintf(buf, buflen, "%s ", name);
> -               if (ret < 0)
> +               if (unlikely(ret < 0))
>                         return -1;
> -               if ((size_t)ret >= buflen)
> +               if (unlikely((size_t)ret >= buflen))
>                         return -1;
>                 buf += ret;
>                 buflen -= ret;
> @@ -440,7 +440,7 @@
>         unsigned int i;
>         int ret;
> 
> -       if (buflen == 0)
> +       if (unlikely(buflen == 0))
>                 return -1;
> 
>         buf[0] = '\0';
> @@ -451,9 +451,9 @@
>                 if (name == NULL)
>                         name = tx_flags[i].default_name;
>                 ret = snprintf(buf, buflen, "%s ", name);
> -               if (ret < 0)
> +               if (unlikely(ret < 0))
>                         return -1;
> -               if ((size_t)ret >= buflen)
> +               if (unlikely((size_t)ret >= buflen))
>                         return -1;
>                 buf += ret;
>                 buflen -= ret;
> 
> 
> Med venlig hilsen / kind regards
> - Morten Brørup

Yes, this makes sense.

Please format patch with signed-off-by and submit according to
the contributing guidelines Creating Patches section.

https://doc.dpdk.org/guides/contributing/patches.html

^ permalink raw reply

* Re: [Qemu-devel] [PATCH for-3.0] tests/libqtest: Improve kill_qemu() assert
From: Eric Blake @ 2018-07-23 19:46 UTC (permalink / raw)
  To: Peter Maydell
  Cc: QEMU Developers, Michael S . Tsirkin, Richard Henderson,
	Alex Bennée, Philippe Mathieu-Daudé, patches@linaro.org
In-Reply-To: <CAFEAcA-v_ntRi9rvAHP8_S+y45T5u02TVY4KdFVii6u6QJi=yg@mail.gmail.com>

On 07/23/2018 02:02 PM, Peter Maydell wrote:
> On 23 July 2018 at 19:59, Eric Blake <eblake@redhat.com> wrote:
>> In other words, why are we special-casing death-by-coredump, when ALL
>> non-zero exit status (whether or not a core dump was involved) is contrary
>> to the assumptions of the testsuite?
> 
> Because we're trying to get as much actual information
> as we have out into the logs, not merely "die so the test
> fails"...

Fair enough; so I posted a v2 based on your starting point:

https://lists.gnu.org/archive/html/qemu-devel/2018-07/msg04438.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

^ permalink raw reply

* (no subject)
From: Marc Eshel @ 2018-07-23 18:43 UTC (permalink / raw)
  To: Bruce Fields
  Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list,
	linux-nfs-owner
In-Reply-To: <20180711152521.8238-1-steved@redhat.com>

Hi Bruce,
Do you know of any plans to add  IETF RFC 8276 - File System Extended 
Attributes in NFSv4 to the Linux NFS Client or Server?
Marc.


^ permalink raw reply

* Re: [PATCH 06/14] format-patch: allow --interdiff to apply to a lone-patch
From: Eric Sunshine @ 2018-07-23 19:46 UTC (permalink / raw)
  To: Nguyễn Thái Ngọc Duy
  Cc: Git List, Johannes Schindelin,
	Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8Aw6R8-3kDfhCqunXziajCg9O_1WrEYc4rfKa+-=m1D5g@mail.gmail.com>

On Mon, Jul 23, 2018 at 12:22 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > +       if (cmit_fmt_is_mail(ctx.fmt) && opt->idiff_oid1) {
>
> OK putting idiff stuff in rev_info is probably the right choice. But
> we all three fields prefixed with idiff_, maybe you could just add a
> new struct "idiff_options" to contain them and add a pointer to that
> struct in rev_info. Then "opt->idiff" is enough to know if idiff is
> requested instead of relying on idiff_oid1 (seems too random).

I have mixed feelings about this suggestion for the following reasons:

* 'struct rev_info' already contains a number of specialized fields
which apply in only certain use cases but not others, and those fields
often are grouped textually to show relationship rather than being
bundled in a struct.

* These new fields are very specific to this particular operation and
are unlikely to ever have wider use, so adding the extra level of
indirection/abstraction (whatever you'd call it) feels overkill and,
while nice theoretically, adds complexity without much practical
value.

* Bundling these fields in a struct might incorrectly imply to readers
that these items, collectively, can be used in some general-purpose
fashion, which isn't at all the case; they are very specific to this
operation and that struct would never be used elsewhere or for any
other purpose.

The upside of bundling them in a struct, as you mention, is that
"opt->idiff" would be slightly more obvious than "opt->idiff_oid1" as
a "should we print an interdiff?" conditional. On the other hand, this
case is so specific and narrow that I'm not sure it warrants such
generality.

^ permalink raw reply

* Re: [PATCH bpf] bpf: btf: Ensure the member->offset is in the right order
From: Yonghong Song @ 2018-07-23 18:45 UTC (permalink / raw)
  To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann, kernel-team
In-Reply-To: <20180721003837.2772516-1-kafai@fb.com>



On 7/20/18 5:38 PM, Martin KaFai Lau wrote:
> This patch ensures the member->offset of a struct
> is in the correct order (i.e the later member's offset cannot
> go backward).
> 
> The current "pahole -J" BTF encoder does not generate something
> like this.  However, checking this can ensure future encoder
> will not violate this.
> 
> Fixes: 69b693f0aefa ("bpf: btf: Introduce BPF Type Format (BTF)")
> Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: Yonghong Song <yhs@fb.com>

^ permalink raw reply

* Re: [PATCH 1/9] contrib: add a script to initialize VS Code configuration
From: Junio C Hamano @ 2018-07-23 19:48 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
In-Reply-To: <e2e449a00385531d326d6811a871dde59624b818.1532353966.git.gitgitgadget@gmail.com>

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> diff --git a/contrib/vscode/init.sh b/contrib/vscode/init.sh
> new file mode 100755
> index 000000000..3cc93243f
> --- /dev/null
> +++ b/contrib/vscode/init.sh
> @@ -0,0 +1,165 @@
> +#!/bin/sh

This is caued by our usual "git apply --whitespace=warn" as it
contains lines indented by spaces not tabs (perhaps the json
literals?)  Can we have contrib/vscode/.gitattributes to tweak the
whitespace breakage checking rules so that this file is excempt?

I'll just shut my eyes while applying this series for today, though
;-)

^ permalink raw reply

* IETF RFC 8276 - File System Extended Attributes in NFSv4
From: Marc Eshel @ 2018-07-23 18:45 UTC (permalink / raw)
  To: Bruce Fields
  Cc: Libtirpc-devel Mailing List, Linux NFS Mailing list,
	linux-nfs-owner
In-Reply-To: <OFA232E502.EADD3A82-ON882582D3.00667F9D-882582D3.0066E08D@LocalDomain>

Hi Bruce,
Do you know of any plans to add  IETF RFC 8276 - File System Extended 
Attributes in NFSv4 to the Linux NFS Client or Server?
Marc.




^ permalink raw reply

* ✓ Fi.CI.BAT: success for drm/i915/icl: Add DSS_CTL Registers
From: Patchwork @ 2018-07-23 19:50 UTC (permalink / raw)
  To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <1532373080-8962-1-git-send-email-anusha.srivatsa@intel.com>

== Series Details ==

Series: drm/i915/icl: Add DSS_CTL Registers
URL   : https://patchwork.freedesktop.org/series/47082/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4530 -> Patchwork_9750 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/47082/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_9750 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_workarounds:
      fi-kbl-7560u:       PASS -> DMESG-FAIL (fdo#107292)

    igt@gem_exec_suspend@basic-s4-devices:
      fi-glk-j4005:       PASS -> DMESG-WARN (fdo#106097)

    igt@kms_chamelium@dp-crc-fast:
      fi-kbl-7500u:       PASS -> DMESG-FAIL (fdo#103841)

    igt@kms_flip@basic-flip-vs-wf_vblank:
      fi-glk-j4005:       PASS -> FAIL (fdo#100368)

    
    ==== Possible fixes ====

    igt@debugfs_test@read_all_entries:
      fi-snb-2520m:       INCOMPLETE (fdo#103713) -> PASS

    igt@drv_selftest@live_workarounds:
      fi-skl-6700hq:      DMESG-FAIL (fdo#107292) -> PASS

    igt@gem_exec_suspend@basic-s3:
      fi-glk-j4005:       DMESG-WARN (fdo#106097) -> PASS

    igt@kms_chamelium@dp-edid-read:
      fi-kbl-7500u:       FAIL (fdo#103841) -> PASS

    igt@kms_flip@basic-flip-vs-wf_vblank:
      fi-glk-dsi:         FAIL (fdo#100368) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (50 -> 43) ==

  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-caroline fi-byt-clapper 


== Build changes ==

    * Linux: CI_DRM_4530 -> Patchwork_9750

  CI_DRM_4530: d27cc4a37a5cc1ef14a3aafdcb6682e5f6a85d09 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9750: 5f0003a0e20267007302ae46a29a033798e7a419 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5f0003a0e202 drm/i915/icl: Add DSS_CTL Registers

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9750/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* Re: [PATCH 1/4] kubernetes: explicitly build for $TARGET_ARCH
From: Bruce Ashfield @ 2018-07-23 19:51 UTC (permalink / raw)
  To: Koen Kooi; +Cc: Raymond Danks, meta-virtualization, Koen Kooi
In-Reply-To: <20180723144850.17279-1-koen.kooi@linaro.org>

I had to add a QA skip for PN-misc, since in my config it was throwing
a GNU_HASH error.

This is now pushed, thanks for the cleanups.

Cheers,

Bruce

On Mon, Jul 23, 2018 at 10:48 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> 'make all' uses 'uname' to select the build target, leading to compile failures like this:
>
> | arm-angstrom-linux-gnueabi-gcc: error: unrecognized command line option '-m64'
>
> After providing the proper arch to the makefile it will try to use a hardcoded compiler:
>
> | # runtime/cgo
> | exec: "arm-linux-gnueabihf-gcc": executable file not found in $PATH
>
> Fix that up by removing all hardcoded 'CC' entries in golang.sh
>
> Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> ---
>  ...ack-lib-golang.sh-use-CC-from-environment.patch | 40 ++++++++++++++++++++++
>  recipes-containers/kubernetes/kubernetes_git.bb    |  6 ++--
>  2 files changed, 44 insertions(+), 2 deletions(-)
>  create mode 100644 recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
>
> diff --git a/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch b/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
> new file mode 100644
> index 0000000..62d0521
> --- /dev/null
> +++ b/recipes-containers/kubernetes/kubernetes/0001-hack-lib-golang.sh-use-CC-from-environment.patch
> @@ -0,0 +1,40 @@
> +From 9cbb2d523d481053d405ebac830c2074b00d3417 Mon Sep 17 00:00:00 2001
> +From: Koen Kooi <koen.kooi@linaro.org>
> +Date: Mon, 23 Jul 2018 15:28:02 +0200
> +Subject: [PATCH] hack/lib/golang.sh: use CC from environment
> +
> +Toolchain tupples differs, especially when using vendor provides ones.
> +
> +Upstream-status: Inappropriate [embedded specific]
> +Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
> +---
> + hack/lib/golang.sh | 4 ----
> + 1 file changed, 4 deletions(-)
> +
> +diff --git a/hack/lib/golang.sh b/hack/lib/golang.sh
> +index c5d4634..563e2b4b 100755
> +--- a/src/import/hack/lib/golang.sh
> ++++ b/src/import/hack/lib/golang.sh
> +@@ -278,19 +278,15 @@ kube::golang::set_platform_envs() {
> +     case "${platform}" in
> +       "linux/arm")
> +         export CGO_ENABLED=1
> +-        export CC=arm-linux-gnueabihf-gcc
> +         ;;
> +       "linux/arm64")
> +         export CGO_ENABLED=1
> +-        export CC=aarch64-linux-gnu-gcc
> +         ;;
> +       "linux/ppc64le")
> +         export CGO_ENABLED=1
> +-        export CC=powerpc64le-linux-gnu-gcc
> +         ;;
> +       "linux/s390x")
> +         export CGO_ENABLED=1
> +-        export CC=s390x-linux-gnu-gcc
> +         ;;
> +     esac
> +   fi
> +--
> +2.9.5
> +
> diff --git a/recipes-containers/kubernetes/kubernetes_git.bb b/recipes-containers/kubernetes/kubernetes_git.bb
> index 10558ef..33cb933 100644
> --- a/recipes-containers/kubernetes/kubernetes_git.bb
> +++ b/recipes-containers/kubernetes/kubernetes_git.bb
> @@ -7,6 +7,7 @@ maintenance, and scaling of applications. \
>
>  SRCREV_kubernetes = "210c9cd7e1782e9fe46938fe0368556f2166a528"
>  SRC_URI = "git://github.com/kubernetes/kubernetes.git;branch=release-1.11;name=kubernetes \
> +           file://0001-hack-lib-golang.sh-use-CC-from-environment.patch \
>            "
>
>  DEPENDS += "rsync-native \
> @@ -46,6 +47,7 @@ inherit goarch
>
>  do_compile() {
>         export GOARCH="${TARGET_GOARCH}"
> +       export GOOS="${TARGET_GOOS}"
>         export GOROOT="${STAGING_LIBDIR_NATIVE}/${TARGET_SYS}/go"
>         export GOPATH="${S}/src/import:${S}/src/import/vendor"
>
> @@ -72,7 +74,7 @@ do_compile() {
>
>         cd ${S}/src/import
>         # to limit what is built, use 'WHAT', i.e. make WHAT=cmd/kubelet
> -       make all
> +       make cross KUBE_BUILD_PLATFORMS=${GOOS}/${GOARCH}
>  }
>
>  do_install() {
> @@ -82,7 +84,7 @@ do_install() {
>
>      install -d ${D}${sysconfdir}/kubernetes/manifests/
>
> -    install -m 755 -D ${S}/src/import/_output/bin/kube* ${D}/${bindir}
> +    install -m 755 -D ${S}/src/import/_output/local/bin/${TARGET_GOOS}/${TARGET_GOARCH}/* ${D}/${bindir}
>
>      install -m 0644 ${S}/src/import/build/debs/kubelet.service  ${D}${systemd_unitdir}/system/
>      install -m 0644 ${S}/src/import/build/debs/10-kubeadm.conf  ${D}${systemd_unitdir}/system/kubelet.service.d/
> --
> 2.9.5
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


^ permalink raw reply

* Re: [PATCH 3/5] drm/amdgpu: enable system interrupt for jrbc
From: Boyuan Zhang @ 2018-07-23 19:53 UTC (permalink / raw)
  To: Alex Deucher, Boyuan Zhang; +Cc: amd-gfx list
In-Reply-To: <CADnq5_NFgHpv4Z_2scvRC8y6EYPqUtnsvGXF6g2mD4yEKuQGOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



On 2018-07-19 02:51 PM, Alex Deucher wrote:
> On Wed, Jul 18, 2018 at 4:39 PM,  <boyuan.zhang@amd.com> wrote:
>> From: Boyuan Zhang <boyuan.zhang@amd.com>
>>
>> Enable system interrupt for jrbc during engine starting time.
>>
>> Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
>> ---
>>   drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> index 4fccb21..22c1588 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
>> @@ -595,6 +595,7 @@ static int vcn_v1_0_start(struct amdgpu_device *adev)
>>          struct amdgpu_ring *ring = &adev->vcn.ring_dec;
>>          uint32_t rb_bufsz, tmp;
>>          uint32_t lmi_swap_cntl;
>> +       uint32_t reg_temp;
>>          int i, j, r;
>>
>>          /* disable byte swapping */
>> @@ -700,6 +701,11 @@ static int vcn_v1_0_start(struct amdgpu_device *adev)
>>                  (UVD_MASTINT_EN__VCPU_EN_MASK|UVD_MASTINT_EN__SYS_EN_MASK),
>>                  ~(UVD_MASTINT_EN__VCPU_EN_MASK|UVD_MASTINT_EN__SYS_EN_MASK));
>>
>> +       /* enable system interrupt for JRBC*/
>> +       reg_temp = RREG32(SOC15_REG_OFFSET(UVD, 0, mmUVD_SYS_INT_EN));
>> +       reg_temp |= UVD_SYS_INT_EN__UVD_JRBC_EN_MASK;
>> +       WREG32(SOC15_REG_OFFSET(UVD, 0, mmUVD_SYS_INT_EN), reg_temp);
>> +
> Shouldn't we move the setting of these interrupts into
> vcn_v1_0_set_interrupt_state()? Same for the mastint.  that way they
> will get enabled/disabled as part of the fence driver sequence I
> think.  Or do they need to happen in a specific sequence?
>
> Alex

Hmm... at least for this JPEG specific case, interrupt won't be raised 
during those times that we don't care about the interrupt. This is not 
like other system component where interrupt might still be raised even 
if we don't care about it. So my feeling is that whether we disable it 
at the beginning and enable it later on, or we just enable it at the 
beginning doesn't really matter in the practical sense.

Regards,
Boyuan

>
>>          /* clear the bit 4 of VCN_STATUS */
>>          WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_STATUS), 0,
>>                          ~(2 << UVD_STATUS__VCPU_REPORT__SHIFT));
>> @@ -1754,7 +1760,7 @@ static const struct amdgpu_irq_src_funcs vcn_v1_0_irq_funcs = {
>>
>>   static void vcn_v1_0_set_irq_funcs(struct amdgpu_device *adev)
>>   {
>> -       adev->vcn.irq.num_types = adev->vcn.num_enc_rings + 1;
>> +       adev->vcn.irq.num_types = adev->vcn.num_enc_rings + 2;
>>          adev->vcn.irq.funcs = &vcn_v1_0_irq_funcs;
>>   }
>>
>> --
>> 2.7.4
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* Re: [PATCH] [meta-cloud-services][patch]:python-sphinx:1.4.1->1.7.6
From: Bruce Ashfield @ 2018-07-23 19:53 UTC (permalink / raw)
  To: Hong Liu; +Cc: meta-virtualization
In-Reply-To: <20180723090011.11902-1-hongl.fnst@cn.fujitsu.com>

merged

Bruce

On Mon, Jul 23, 2018 at 5:00 AM, Hong Liu <hongl.fnst@cn.fujitsu.com> wrote:
> 1.Upgrade python-sphinx from 1.4.1 to 1.7.6.
>
> 2.Modify LIC_FILES_CHKSUM,because of delete "PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2"
>
> Signed-off-by: Hong Liu <hongl.fnst@cn.fujitsu.com>
> ---
>  recipes-devtools/python/python-sphinx_1.4.1.bb | 12 ------------
>  recipes-devtools/python/python-sphinx_1.7.6.bb | 12 ++++++++++++
>  2 files changed, 12 insertions(+), 12 deletions(-)
>  delete mode 100644 recipes-devtools/python/python-sphinx_1.4.1.bb
>  create mode 100644 recipes-devtools/python/python-sphinx_1.7.6.bb
>
> diff --git a/recipes-devtools/python/python-sphinx_1.4.1.bb b/recipes-devtools/python/python-sphinx_1.4.1.bb
> deleted file mode 100644
> index 476ff97..0000000
> --- a/recipes-devtools/python/python-sphinx_1.4.1.bb
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -DESCRIPTION = "Python documentation generator"
> -HOMEPAGE = "http://sphinx-doc.org/"
> -SECTION = "devel/python"
> -LICENSE = "BSD"
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=72f034adc6f7b05b09bc00d1a05bb065"
> -
> -PYPI_PACKAGE = "Sphinx"
> -
> -SRC_URI[md5sum] = "4c4988e0306a04cef8dccc384281e585"
> -SRC_URI[sha256sum] = "c6871a784d24aba9270b6b28541537a57e2fcf4d7c799410eba18236bc76d6bc"
> -
> -inherit setuptools pypi
> diff --git a/recipes-devtools/python/python-sphinx_1.7.6.bb b/recipes-devtools/python/python-sphinx_1.7.6.bb
> new file mode 100644
> index 0000000..0200c9e
> --- /dev/null
> +++ b/recipes-devtools/python/python-sphinx_1.7.6.bb
> @@ -0,0 +1,12 @@
> +DESCRIPTION = "Python documentation generator"
> +HOMEPAGE = "http://sphinx-doc.org/"
> +SECTION = "devel/python"
> +LICENSE = "BSD"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=89cbefcd0a80481e8b26a9a7d25be749"
> +
> +PYPI_PACKAGE = "Sphinx"
> +
> +SRC_URI[md5sum] = "8fbd77d80c8e0966964751ab31a0204a"
> +SRC_URI[sha256sum] = "217ad9ece2156ed9f8af12b5d2c82a499ddf2c70a33c5f81864a08d8c67b9efc"
> +
> +inherit setuptools pypi
> --
> 2.7.4
>
>
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


^ permalink raw reply

* Re: [PATCH] [meta-cloud-services][patch]:tgt:1.0.67 -> 1.0.73
From: Bruce Ashfield @ 2018-07-23 19:53 UTC (permalink / raw)
  To: Hong Liu; +Cc: meta-virtualization
In-Reply-To: <20180723090011.11902-2-hongl.fnst@cn.fujitsu.com>

merged.

Bruce

On Mon, Jul 23, 2018 at 5:00 AM, Hong Liu <hongl.fnst@cn.fujitsu.com> wrote:
> Upgrade tgt from 1.0.67 to 1.0.73
>
> Signed-off-by: Hong Liu <hongl.fnst@cn.fujitsu.com>
> ---
>  meta-openstack/recipes-support/tgt/tgt_git.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta-openstack/recipes-support/tgt/tgt_git.bb b/meta-openstack/recipes-support/tgt/tgt_git.bb
> index 9ca181a..f4e12da 100644
> --- a/meta-openstack/recipes-support/tgt/tgt_git.bb
> +++ b/meta-openstack/recipes-support/tgt/tgt_git.bb
> @@ -4,8 +4,8 @@ LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM = "file://scripts/tgtd.spec;beginline=7;endline=7;md5=21c19ea7dad04648b9c2f791b6e29b4c"
>  DEPENDS = "sg3-utils"
>
> -SRCREV = "cb7971cfeecaa43c15eed4719dc82516d7e87b6c"
> -PV = "1.0.67+git${SRCPV}"
> +SRCREV = "013223dc886a03719ca02db52162056249d99448"
> +PV = "1.0.73+git${SRCPV}"
>
>  SRC_URI = "git://github.com/fujita/tgt.git \
>         file://0001-Correct-the-path-of-header-files-check-in-Yocto-buil.patch \
> --
> 2.7.4
>
>
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


^ permalink raw reply

* Re: [PATCH v10 7/7] Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990
From: Matthias Kaehlcke @ 2018-07-23 19:54 UTC (permalink / raw)
  To: Balakrishna Godavarthi
  Cc: marcel, johan.hedberg, linux-kernel, devicetree, linux-bluetooth,
	thierry.escande, rtatiya, hemantg, linux-arm-msm
In-Reply-To: <20180720133243.6851-8-bgodavar@codeaurora.org>

On Fri, Jul 20, 2018 at 07:02:43PM +0530, Balakrishna Godavarthi wrote:
> Add support to set voltage/current of various regulators
> to power up/down Bluetooth chip wcn3990.
> 
> Signed-off-by: Balakrishna Godavarthi <bgodavar@codeaurora.org>
> ---
> changes in v10:
>     * added support to read regulator currents from dts.

I commented on this below

>     * added support to try to connect with chip if it fails to respond to initial commands
>     * updated review comments.
> 
> changes in v9:
>     * moved flow control to vendor and set_baudarte functions.
>     * removed parent regs.
> 
> changes in v8:
>     * closing qca buffer, if qca_power_setup fails
>     * chnaged ibs start timer function call location.
>     * updated review comments.
>   
> changes in v7:
>     * addressed review comments.
> 
> changes in v6:
>     * Hooked up qca_power to qca_serdev.
>     * renamed all the naming inconsistency functions with qca_*
>     * leveraged common code of ROME for wcn3990.
>     * created wrapper functions for re-usable blocks.
>     * updated function of _*regulator_enable and _*regualtor_disable.  
>     * removed redundant comments and functions.
>     * addressed review comments.
> 
> Changes in v5:
>     * updated regulator vddpa min_uV to 1304000.
>       * addressed review comments.
>  
> Changes in v4:
>     * Segregated the changes of btqca from hci_qca
>     * rebased all changes on top of bluetooth-next.
>     * addressed review comments.
> 
> ---
>  drivers/bluetooth/btqca.h   |   4 +
>  drivers/bluetooth/hci_qca.c | 481 ++++++++++++++++++++++++++++++++----
>  2 files changed, 439 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
> index a9c2779f3e07..9e2bbcf5c002 100644
> --- a/drivers/bluetooth/btqca.h
> +++ b/drivers/bluetooth/btqca.h
> @@ -37,6 +37,10 @@
>  #define EDL_TAG_ID_HCI			(17)
>  #define EDL_TAG_ID_DEEP_SLEEP		(27)
>  
> +#define QCA_WCN3990_POWERON_PULSE	0xFC
> +#define QCA_WCN3990_POWEROFF_PULSE	0xC0
> +#define QCA_WCN3990_FORCE_BOOT_PULSE	0xC0

This is the same value as QCA_WCN3990_POWEROFF_PULSE. From the usage
it seems it's really just a power off pulse, so let's stick to this
name, instead of having two names for the same thing.

> +static int qca_send_vendor_pulse(struct hci_dev *hdev, u8 cmd)

My understanding from earlier discussion is that these pulses are
limited to power on/off. If that is correct this should probably be
called qca_send_power_pulse().

> +{
> +	struct hci_uart *hu = hci_get_drvdata(hdev);
> +	struct qca_data *qca = hu->priv;
> +	struct sk_buff *skb;
> +
> +	/* These vendor pulses are single byte command which are sent
> +	 * at required baudrate to WCN3990. on WCN3990, we have an external

s/on/On/

> +	 * circuit at Tx pin which decodes the pulse sent at specific baudrate.
> +	 * For example, as WCN3990 supports RF COEX frequency for both Wi-Fi/BT
> +	 * and also, we use the same power inputs to turn ON and OFF for

nit: not sure how much value is added by (sometimes) using upper case
for certain things (ON, OFF, COLD, HOST, ...).

> +	 * Wi-Fi/BT. Powering up the power sources will not enable BT, until
> +	 * we send a POWER ON pulse at 115200. This algorithm will help to

115200 what? bps I guess.

> +static int qca_wcn3990_init(struct hci_uart *hu, u32 *soc_ver)
> +{
> +	struct hci_dev *hdev = hu->hdev;
> +	int i, ret = 1;

Initialization not necessary, more details below.

> +
> +	/* WCN3990 is a discrete Bluetooth chip connected to APPS processor.

APPS is a Qualcomm specific term, and some QCA docs also call it
APSS. Just say 'SoC' which is universally understood.

> +	 * sometimes we will face communication synchronization issues,
> +	 * like reading version command timeouts. In which HCI_SETUP fails,
> +	 * to overcome these issues, we try to communicate by performing an
> +	 * COLD power OFF and ON.
> +	 */
> +	for (i = 1; i <= 10 && ret; i++) {

Is it really that bad that more than say 3 iterations might be needed?

Common practice is to start loops with index 0.

The check for ret is not needed. All jumps to 'regs_off' are done
when an error is detected. The loop is left when 'ret == 0' at the
bottom.

> +		/* This helper will turn ON chip if it is powered off.
> +		 * if the chip is already powered ON, function call will
> +		 * return zero.
> +		 */

Comments are great when they add value, IMO this one doesn't and just
adds distraction. Most readers will assume that after
qca_power_setup(hu, true) the chip is powered on, regardless of the
previous power state.

> +		ret = qca_power_setup(hu, true);
> +		if (ret)
> +			goto regs_off;
> +
> +		/* Forcefully enable wcn3990 to enter in to boot mode. */

nit: Sometimes the comments and logs name the chip wcn3990, others
WCN3990. Personally I don't care which spelling is used, but please be
consistent.

> +		host_set_baudrate(hu, 2400);
> +		ret = qca_send_vendor_pulse(hdev, QCA_WCN3990_FORCE_BOOT_PULSE);
> +		if (ret)
> +			goto regs_off;
> +
> +		qca_set_speed(hu, QCA_INIT_SPEED);
> +		ret = qca_send_vendor_pulse(hdev, QCA_WCN3990_POWERON_PULSE);
> +		if (ret)
> +			goto regs_off;
> +
> +		/* Wait for 100 ms for SoC to boot */
> +		msleep(100);
> +
> +		/* Now the device is in ready state to communicate with host.
> +		 * To sync HOST with device we need to reopen port.
> +		 * Without this, we will have RTS and CTS synchronization
> +		 * issues.
> +		 */
> +		serdev_device_close(hu->serdev);
> +		ret = serdev_device_open(hu->serdev);
> +		if (ret) {
> +			bt_dev_err(hu->hdev, "failed to open port");
> +			break;
> +		}
> +
> +		hci_uart_set_flow_control(hu, false);
> +		ret = qca_read_soc_version(hdev, soc_ver);
> +		if (ret < 0 || soc_ver == 0)
> +			bt_dev_err(hdev, "Failed to get version:%d", ret);

The check for soc_ver is/should be done in qca_read_soc_version(),
same for the error log.

> +		if (!ret)
> +			break;
> +
> +regs_off:
> +		bt_dev_err(hdev, "retrying to establish communication: %d", i);

Use i + 1 if starting the loop at 0.

> +static const struct qca_vreg_data qca_soc_data = {
> +	.soc_type = QCA_WCN3990,
> +	.vregs = (struct qca_vreg []) {
> +		{ "vddio",   1800000, 1800000,  15000  },
> +		{ "vddxo",   1800000, 1800000,  80000  },
> +		{ "vddrf",   1304000, 1304000,  300000 },
> +		{ "vddch0",  3000000, 3312000,  450000 },
> +	},

The currents of 300mA and 450mA seem high for Bluetooth, I'm not an
expert in this area though, they might be reasonable peak currents for
certain use cases.

> +static int qca_power_shutdown(struct hci_dev *hdev)
> +{
> +	struct hci_uart *hu = hci_get_drvdata(hdev);
> +
> +	host_set_baudrate(hu, 2400);
> +	qca_send_vendor_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE);
> +	return qca_power_setup(hu, false);
> +}

The return value changed from void to int, but nobody ever checks it ...

> +static void qca_regulator_get_current(struct device *dev,
> +				      struct qca_vreg *vregs)
> +{
> +	char prop_name[32]; /* 32 is max size of property name */
> +
> +	/* We have different platforms where the load value is controlled
> +	 * via PMIC controllers. In such cases load required to power ON
> +	 * Bluetooth chips are defined in the PMIC. We have option to set
> +	 * operation mode like high or low power modes.
> +	 * We do have some platforms where driver need to enable the load for
> +	 * WCN3990. Based on the current property value defined for the
> +	 * regulators, driver will decide the regulator output load.
> +	 * If the current property for the regulator is defined in the dts
> +	 * we will read from dts tree, else from the default load values.
> +	 */

Let's make sure we all really understand why this is needed. You
mentioned RPMh regulators earlier and said a special value of 1uA
would be needed to enable high power mode. Later when I pointed to the
RPMh regulator code you agreed that this special value wouldn't make
any difference.

Now the defaults are higher:

> +		{ "vddio",   1800000, 1800000,  15000  },
> +		{ "vddxo",   1800000, 1800000,  80000  },
> +		{ "vddrf",   1304000, 1304000,  300000 },
> +		{ "vddch0",  3000000, 3312000,  450000 },

What would supposedly go wrong if these values were passed to one of
the PMICs you are concerned about? Please be more specific than the
above comment.

> +	snprintf(prop_name, 32, "%s-current", vregs->name);
> +	BT_DBG("Looking up %s from device tree\n", prop_name);

'\n' not needed with BT_DBG()

> +
> +	if (device_property_read_bool(dev, prop_name))
> +		device_property_read_u32(dev, prop_name, &vregs->load_uA);

Why device_property_read_bool()?

> +	BT_DBG("current %duA selected for regulator %s", vregs->load_uA,
> +		vregs->name);
> +}
> +
> +static int qca_init_regulators(struct qca_power *qca,
> +				const struct qca_vreg_data *data)
> +{
> +	int i, num_vregs;
> +	int load_uA;
> +
> +	num_vregs = data->num_vregs;
> +	qca->vreg_bulk = devm_kzalloc(qca->dev, num_vregs *
> +				      sizeof(struct regulator_bulk_data),
> +				      GFP_KERNEL);
> +	if (!qca->vreg_bulk)
> +		return -ENOMEM;
> +
> +	qca->vreg_data = devm_kzalloc(qca->dev, sizeof(struct qca_vreg_data),
> +				      GFP_KERNEL);
> +	if (!qca->vreg_data)
> +		return -ENOMEM;
> +
> +	qca->vreg_data->num_vregs = data->num_vregs;
> +	qca->vreg_data->soc_type = data->soc_type;
> +
> +	qca->vreg_data->vregs = devm_kzalloc(qca->dev, num_vregs *
> +				      sizeof(struct qca_vreg_data),

sizeof(struct qca_vreg)

> +				      GFP_KERNEL);
> +
> +	if (!qca->vreg_data->vregs)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num_vregs; i++) {
> +		/* copy regulator name, min voltage, max voltage */
> +		qca->vreg_data->vregs[i].name = data->vregs[i].name;
> +		qca->vreg_data->vregs[i].min_uV = data->vregs[i].min_uV;
> +		qca->vreg_data->vregs[i].max_uV = data->vregs[i].max_uV;
> +		load_uA = data->vregs[i].load_uA;
> +		qca->vreg_data->vregs[i].load_uA = load_uA;

memcpy(&qca->vreg_data->vregs[i], &data->vregs[i]); ?

Or do it outside of the loop for all regulators at once.

>  static int qca_serdev_probe(struct serdev_device *serdev)
>  {
>  	struct qca_serdev *qcadev;
> +	const struct qca_vreg_data *data;
>  	int err;
>  
>  	qcadev = devm_kzalloc(&serdev->dev, sizeof(*qcadev), GFP_KERNEL);
> @@ -1069,47 +1418,87 @@ static int qca_serdev_probe(struct serdev_device *serdev)
>  		return -ENOMEM;
>  
>  	qcadev->serdev_hu.serdev = serdev;
> +	data = of_device_get_match_data(&serdev->dev);
>  	serdev_device_set_drvdata(serdev, qcadev);
> +	if (data && data->soc_type == QCA_WCN3990) {
> +		qcadev->btsoc_type = QCA_WCN3990;
> +		qcadev->bt_power = devm_kzalloc(&serdev->dev,
> +						sizeof(struct qca_power),
> +						GFP_KERNEL);
> +		if (!qcadev->bt_power)
> +			return -ENOMEM;
> +
> +		qcadev->bt_power->dev = &serdev->dev;
> +		err = qca_init_regulators(qcadev->bt_power, data);
> +		if (err) {
> +			BT_ERR("Failed to init regulators:%d", err);
> +			goto out;
> +		}
>  
> -	qcadev->bt_en = devm_gpiod_get(&serdev->dev, "enable",
> -				       GPIOD_OUT_LOW);
> -	if (IS_ERR(qcadev->bt_en)) {
> -		dev_err(&serdev->dev, "failed to acquire enable gpio\n");
> -		return PTR_ERR(qcadev->bt_en);
> -	}
> +		qcadev->bt_power->vregs_on = false;
>  
> -	qcadev->susclk = devm_clk_get(&serdev->dev, NULL);
> -	if (IS_ERR(qcadev->susclk)) {
> -		dev_err(&serdev->dev, "failed to acquire clk\n");
> -		return PTR_ERR(qcadev->susclk);
> -	}
> +		/* Read max speed supported by wcn3990 from dts
> +		 * tree. if max-speed property is not enabled in
> +		 * dts, QCA driver will use default operating speed
> +		 * from proto structure.
> +		 */

The comment doesn't add much value.

> +		device_property_read_u32(&serdev->dev, "max-speed",
> +					 &qcadev->oper_speed);
> +		if (!qcadev->oper_speed)
> +			BT_INFO("UART will pick default operating speed");

Not a change in this version, but BT_INFO seems a bit verbose, we
should avoid spamming the kernel log.

^ permalink raw reply

* ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev3)
From: Patchwork @ 2018-07-23 19:54 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>

== Series Details ==

Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev3)
URL   : https://patchwork.freedesktop.org/series/47067/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
fbfeaf105d25 drm/i915: Skip repeated calls to i915_gem_set_wedged()
-:60: WARNING:MEMORY_BARRIER: memory barrier without comment
#60: FILE: drivers/gpu/drm/i915/i915_gem.c:3388:
+	smp_mb__before_atomic();

total: 0 errors, 1 warnings, 0 checks, 73 lines checked

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply

* [rocko/master][PATCHv2] tidl-utils: SRCREV bump
From: Djordje Senicic @ 2018-07-23 19:54 UTC (permalink / raw)
  To: meta-arago; +Cc: d-senicic1, Djordje Senicic

* Get new version of tidl-utils configuration files with fixed path
* RDEPENDS is not needed for x86 target, as executables are statically linked

Signed-off-by: Djordje Senicic <x0157990@ti.com>
---
 meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
index 264b030..569de5a 100644
--- a/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
+++ b/meta-arago-extras/recipes-ti/tidl-utils/tidl-utils.bb
@@ -8,10 +8,10 @@ INC_PR = "r0"
 
 LIC_FILES_CHKSUM = "file://docs/LICENSE.txt;md5=a93aa5af7a3bbbb6fb34c8df59efaa5c"
 
-RDEPENDS_${PN} += " tidl-api tidl-examples "
+RDEPENDS_${PN}_class-target += " tidl-api tidl-examples "
 
 SRC_URI = "git://git.ti.com/tidl/tidl-utils.git;protocol=git;branch=master"
-SRCREV = "93f66d2c53960b13b7e7f20208ee205f727aaf28"
+SRCREV = "994d90ae583610673d9d39086ca5e84027a9c56e"
 
 PR = "${INC_PR}.0"
 
-- 
1.9.1



^ permalink raw reply related

* [PATCH v4] drm/i915: Skip repeated calls to i915_gem_set_wedged()
From: Chris Wilson @ 2018-07-23 19:56 UTC (permalink / raw)
  To: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>

If we already wedged, i915_gem_set_wedged() becomes a complicated no-op.

v2: Make sure the double set-wedged is synchronous, a parallel call
should not return before the driver is indeed wedged.

References: https://bugs.freedesktop.org/show_bug.cgi?id=107343
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem.c       | 32 ++++++++++++++++++++++-----
 drivers/gpu/drm/i915/i915_gpu_error.h |  3 ++-
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8b52cb768a67..912be7356984 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3298,12 +3298,27 @@ static void nop_complete_submit_request(struct i915_request *request)
 	spin_unlock_irqrestore(&request->engine->timeline.lock, flags);
 }
 
+static void wait_for_wedged(struct i915_gpu_error *error)
+{
+	DEFINE_WAIT_BIT(wq_entry, &error->flags, I915_WEDGED);
+
+	__wait_on_bit(&error->reset_queue,
+		      &wq_entry, bit_wait, TASK_UNINTERRUPTIBLE);
+}
+
 void i915_gem_set_wedged(struct drm_i915_private *i915)
 {
+	struct i915_gpu_error *error = &i915->gpu_error;
 	struct intel_engine_cs *engine;
 	enum intel_engine_id id;
 
-	GEM_TRACE("start\n");
+	if (test_bit(I915_WEDGED, &error->flags))
+		return;
+
+	if (test_and_set_bit(I915_WEDGE_IN_PROGRESS, &error->flags)) {
+		wait_for_wedged(error);
+		return;
+	}
 
 	if (GEM_SHOW_DEBUG()) {
 		struct drm_printer p = drm_debug_printer(__func__);
@@ -3312,8 +3327,7 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 			intel_engine_dump(engine, &p, "%s\n", engine->name);
 	}
 
-	set_bit(I915_WEDGED, &i915->gpu_error.flags);
-	smp_mb__after_atomic();
+	GEM_TRACE("start\n");
 
 	/*
 	 * First, stop submission to hw, but do not yet complete requests by
@@ -3372,17 +3386,25 @@ void i915_gem_set_wedged(struct drm_i915_private *i915)
 		i915_gem_reset_finish_engine(engine);
 	}
 
+	smp_mb__before_atomic();
+	set_bit(I915_WEDGED, &error->flags);
+	clear_bit(I915_WEDGE_IN_PROGRESS, &error->flags);
+
 	GEM_TRACE("end\n");
 
-	wake_up_all(&i915->gpu_error.reset_queue);
+	wake_up_all(&error->reset_queue);
 }
 
 bool i915_gem_unset_wedged(struct drm_i915_private *i915)
 {
+	struct i915_gpu_error *error = &i915->gpu_error;
 	struct i915_timeline *tl;
 
 	lockdep_assert_held(&i915->drm.struct_mutex);
-	if (!test_bit(I915_WEDGED, &i915->gpu_error.flags))
+
+	if (test_bit(I915_WEDGE_IN_PROGRESS, &error->flags))
+		wait_for_wedged(error);
+	if (!test_bit(I915_WEDGED, &error->flags))
 		return true;
 
 	GEM_TRACE("start\n");
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.h b/drivers/gpu/drm/i915/i915_gpu_error.h
index f893a4e8b783..1a78a8f330f2 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.h
+++ b/drivers/gpu/drm/i915/i915_gpu_error.h
@@ -267,8 +267,9 @@ struct i915_gpu_error {
 #define I915_RESET_BACKOFF	0
 #define I915_RESET_HANDOFF	1
 #define I915_RESET_MODESET	2
+#define I915_RESET_ENGINE	3
 #define I915_WEDGED		(BITS_PER_LONG - 1)
-#define I915_RESET_ENGINE	(I915_WEDGED - I915_NUM_ENGINES)
+#define I915_WEDGE_IN_PROGRESS	(I915_WEDGED - 1)
 
 	/** Number of times an engine has been reset */
 	u32 reset_engine_count[I915_NUM_ENGINES];
-- 
2.18.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related

* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD SUCCESS f117974c8e78e6abdcdeeaf31d5352d66dad9694
From: kbuild test robot @ 2018-07-23 19:56 UTC (permalink / raw)
  To: intel-wired-lan

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git  dev-queue
branch HEAD: f117974c8e78e6abdcdeeaf31d5352d66dad9694  ice: Fix missing shift

elapsed time: 119m

configs tested: 122

The following configs have been built successfully.
More configs may be tested in the coming days.

x86_64                           allmodconfig
powerpc                 mpc8560_ads_defconfig
x86_64                 randconfig-a0-07240159
x86_64                             acpi-redef
x86_64                           allyesdebian
x86_64                                nfsroot
sh                                allnoconfig
sh                          rsk7269_defconfig
sh                  sh7785lcr_32bit_defconfig
sh                            titan_defconfig
i386                   randconfig-c0-07231120
mips                        jmr3927_defconfig
sparc64                           allnoconfig
mips                          lasat_defconfig
parisc                         a500_defconfig
x86_64                randconfig-it0-07231322
i386                     randconfig-n0-201829
x86_64                 randconfig-x007-201829
x86_64                 randconfig-x003-201829
x86_64                 randconfig-x000-201829
x86_64                 randconfig-x005-201829
x86_64                 randconfig-x004-201829
x86_64                 randconfig-x008-201829
x86_64                 randconfig-x001-201829
x86_64                 randconfig-x009-201829
x86_64                 randconfig-x002-201829
x86_64                 randconfig-x006-201829
ia64                             alldefconfig
ia64                              allnoconfig
ia64                                defconfig
i386                     randconfig-i0-201829
i386                     randconfig-i1-201829
powerpc                           allnoconfig
powerpc                             defconfig
powerpc                       ppc64_defconfig
s390                        default_defconfig
i386                             allmodconfig
x86_64                 randconfig-x018-201829
x86_64                 randconfig-x011-201829
x86_64                 randconfig-x015-201829
x86_64                 randconfig-x019-201829
x86_64                 randconfig-x014-201829
x86_64                 randconfig-x010-201829
x86_64                 randconfig-x013-201829
x86_64                 randconfig-x016-201829
x86_64                 randconfig-x017-201829
x86_64                 randconfig-x012-201829
i386                     randconfig-a0-201829
i386                     randconfig-a1-201829
x86_64                 randconfig-s0-07231842
x86_64                 randconfig-s1-07231842
x86_64                 randconfig-s2-07231842
alpha                               defconfig
parisc                            allnoconfig
parisc                         b180_defconfig
parisc                        c3000_defconfig
parisc                              defconfig
arm                             ezx_defconfig
m68k                       m5249evb_defconfig
microblaze                        allnoconfig
nds32                               defconfig
i386                             alldefconfig
i386                              allnoconfig
i386                                defconfig
m68k                       m5475evb_defconfig
m68k                          multi_defconfig
m68k                           sun3_defconfig
i386                     randconfig-s0-201829
i386                     randconfig-s1-201829
x86_64                 randconfig-s3-07232252
x86_64                 randconfig-s4-07232252
x86_64                 randconfig-s5-07232252
openrisc                    or1ksim_defconfig
um                             i386_defconfig
um                           x86_64_defconfig
mips                       capcella_defconfig
mips                          rb532_defconfig
sh                         apsh4a3a_defconfig
x86_64                   randconfig-i0-201829
powerpc                      pcm030_defconfig
powerpc                     tqm8548_defconfig
sh                            hp6xx_defconfig
microblaze                      mmu_defconfig
microblaze                    nommu_defconfig
sparc                               defconfig
sparc64                             defconfig
c6x                        evmc6678_defconfig
h8300                    h8300h-sim_defconfig
nios2                         10m50_defconfig
xtensa                       common_defconfig
xtensa                          iss_defconfig
x86_64                 randconfig-u0-07240101
openrisc                          allnoconfig
powerpc                        fsp2_defconfig
s390                       zfcpdump_defconfig
i386                   randconfig-x012-201829
i386                   randconfig-x017-201829
i386                   randconfig-x014-201829
i386                   randconfig-x016-201829
i386                   randconfig-x013-201829
i386                   randconfig-x011-201829
i386                   randconfig-x018-201829
i386                   randconfig-x010-201829
i386                   randconfig-x015-201829
i386                   randconfig-x019-201829
mips                           32r2_defconfig
mips                         64r6el_defconfig
mips                              allnoconfig
mips                      fuloong2e_defconfig
mips                                   jz4740
mips                      malta_kvm_defconfig
mips                                     txx9
i386                   randconfig-x008-201829
i386                   randconfig-x009-201829
i386                   randconfig-x005-201829
i386                   randconfig-x000-201829
i386                   randconfig-x003-201829
i386                   randconfig-x001-201829
i386                   randconfig-x004-201829
i386                   randconfig-x006-201829
i386                   randconfig-x007-201829
i386                   randconfig-x002-201829

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

^ permalink raw reply

* Re: [PATCH 10/14] format-patch: add --range-diff option to embed diff in cover letter
From: Eric Sunshine @ 2018-07-23 19:58 UTC (permalink / raw)
  To: Nguyễn Thái Ngọc Duy
  Cc: Git List, Johannes Schindelin,
	Ævar Arnfjörð Bjarmason, Stefan Beller
In-Reply-To: <CACsJy8AOeiKp2JnG0h9mw40TdsNft80vUu573ORtqKMor7B+vw@mail.gmail.com>

On Mon, Jul 23, 2018 at 12:28 PM Duy Nguyen <pclouds@gmail.com> wrote:
> On Sun, Jul 22, 2018 at 11:58 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> > diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
> > index f8a061794d..e7f404be3d 100644
> > --- a/Documentation/git-format-patch.txt
> > +++ b/Documentation/git-format-patch.txt
> > @@ -24,6 +24,7 @@ SYNOPSIS
> >                    [--to=<email>] [--cc=<email>]
> >                    [--[no-]cover-letter] [--quiet] [--notes[=<ref>]]
> >                    [--interdiff=<previous>]
> > +                  [--range-diff=<previous>]
>
> I wonder if people will use both --interdiff=<rev> and
> --range-diff=<rev> often enough to justify a shortcut
> "--all-kinds-of-diff=<rev>" so that we don't have to type <previous>
> twice. But I guess we don't have to worry about this right now.

My original thought was that --interdiff and --range-diff would be
mutually exclusive, however, I quickly realized that some people might
like to use both options together since each format has its strengths
and weaknesses. (I've used both types of diffs together when preparing
rerolls of my own series and found that, together, they provided a
better picture of the reroll than either would have alone.)

Based upon experience on this mailing list, I'd guess that most people
would use only one or the other, though that doesn't speak for other
projects. And, as you note, it's something that can be added later if
warranted (plus, this series is already long and I'd like to avoid
making it longer for something like this whose value is only
speculative).

^ permalink raw reply

* Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
From: Alan Stern @ 2018-07-23 18:57 UTC (permalink / raw)
  To: Matwey V. Kornilov
  Cc: Tomasz Figa, Ezequiel Garcia, Hans de Goede, Hans Verkuil,
	Mauro Carvalho Chehab, Laurent Pinchart, Steven Rostedt, mingo,
	Mike Isely, Bhumika Goyal, Colin King, Linux Media Mailing List,
	Linux Kernel Mailing List, Kieran Bingham, keiichiw
In-Reply-To: <CAJs94EZEqWEscECp7bsJ3DvqoU83_Y2WQ55jPaG4MyoG-hvLFQ@mail.gmail.com>

On Mon, 23 Jul 2018, Matwey V. Kornilov wrote:

> I've tried to strategies:
> 
> 1) Use dma_unmap and dma_map inside the handler (I suppose this is
> similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP)

Yes.

> 2) Use sync_cpu and sync_device inside the handler (and dma_map only
> once at memory allocation)
> 
> It is interesting that dma_unmap/dma_map pair leads to the lower
> overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform.
> At armv7l platform using dma_unmap/dma_map  leads to ~50 usec in the
> handler, and sync_cpu/sync_device - ~65 usec.
> 
> However, I am not sure is it mandatory to call
> dma_sync_single_for_device for FROM_DEVICE direction?

According to Documentation/DMA-API-HOWTO.txt, the CPU should not write 
to a DMA_FROM_DEVICE-mapped area, so dma_sync_single_for_device() is
not needed.

Alan Stern

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.