* Re: mesh-cfgclient Node is not attached
From: Gix, Brian @ 2020-02-20 19:00 UTC (permalink / raw)
To: nazeer.m@phytec.in, linux-bluetooth@vger.kernel.org
In-Reply-To: <OF2849A126.CB6B1F2C-ONC1258514.0028F058-C1258514.0028F05A@phytec.de>
Hi Mr Nazeer,
On Thu, 2020-02-20 at 08:27 +0100, Mahaboob Nazeer SK wrote:
> Hi,
>
> I was trying to provision a node using a mesh-cfgclient.
>
> I have successfully ran create and i was able to get configuration
> files in the .config.
>
> [mesh-cfgclient]# create
> Mesh network configuration exists (/home/nazeer/.config/meshcfg/config_db.json)
>
> After that i have tried to discover the unprovisioned node but i get
> Node is not attached message.
>
> [mesh-cfgclient]# discover-unprovisioned on
> Node is not attached
> [mesh-cfgclient]#
The problem you describe is probably due to the daemon not finding an appropriate BT controller to attach to.
This led to the "Attach" failing after the "Create", and then none of the commands to the node are able to be
sent.
There are a couple of options here:
1. If you have a single BT Controller (v4 or newer) you will need to disable the main bluetooth daemon so that
the bluetooth-meshd daemon has access to it:
$ sudo systemctl disable bluetooth
$ sudo systemctl stop bluetooth
2. If you have *multiple* BT controllers, make sure the bluetooth daemon hasn't automatically claimed them all:
In /etc/bluetooth/main.conf, make sure AutoEnable=false (reboot may then be required)
In the future, we will be doing work to enable co-existance and controller sharing for single controller
systems. However, this will require some changes in the kernel.
>
> Could you please let me know if weather there are some
> more steps involved to discover and provision a node or if am missing somethings.
>
> Thank you.
Regards,
--Brian Gix
^ permalink raw reply
* Re: [PATCH v1 07/13] migrate/ram: Get rid of "place_source" in ram_load_postcopy()
From: Dr. David Alan Gilbert @ 2020-02-20 18:58 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eduardo Habkost, Juan Quintela, qemu-devel, Peter Xu,
Paolo Bonzini, Richard Henderson
In-Reply-To: <5DD859C1-9FF5-4488-8928-43B83D8AD677@redhat.com>
* David Hildenbrand (david@redhat.com) wrote:
>
>
> > Am 19.02.2020 um 21:47 schrieb Peter Xu <peterx@redhat.com>:
> >
> > On Wed, Feb 19, 2020 at 05:17:19PM +0100, David Hildenbrand wrote:
> >> It's always the same value.
> >
> > I guess not, because...
> >
> >>
> >> Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >> Cc: Juan Quintela <quintela@redhat.com>
> >> Cc: Peter Xu <peterx@redhat.com>
> >> Signed-off-by: David Hildenbrand <david@redhat.com>
> >> ---
> >> migration/ram.c | 8 +++-----
> >> 1 file changed, 3 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/migration/ram.c b/migration/ram.c
> >> index cbd54947fb..75014717f6 100644
> >> --- a/migration/ram.c
> >> +++ b/migration/ram.c
> >> @@ -3119,7 +3119,6 @@ static int ram_load_postcopy(QEMUFile *f)
> >> ram_addr_t addr;
> >> void *host = NULL;
> >> void *page_buffer = NULL;
> >> - void *place_source = NULL;
> >> RAMBlock *block = NULL;
> >> uint8_t ch;
> >> int len;
> >> @@ -3188,7 +3187,6 @@ static int ram_load_postcopy(QEMUFile *f)
> >> place_needed = true;
> >> target_pages = 0;
> >> }
> >> - place_source = postcopy_host_page;
> >> }
> >>
> >> switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
> >> @@ -3220,7 +3218,7 @@ static int ram_load_postcopy(QEMUFile *f)
> >> * buffer to make sure the buffer is valid when
> >> * placing the page.
> >> */
> >> - qemu_get_buffer_in_place(f, (uint8_t **)&place_source,
> >
> > ... it can be modified inside the call.
>
> Very right, will drop this patch! Thanks!
>
> >
> > I feel like this patch could even fail the QEMU unit test. It would
> > be good to mention what tests have been carried out in the cover
> > letter or with RFC tag if no test is done yet.
>
> I test all code I share. This survives „make check“. I assume all tests send small pages where „matches_target_page_size==true“, so the tests did not catch this.
>
> I even spent the last day getting avocado-vt to work and ran multiple (obviously not all) migration tests, including postcopy, so your suggestions have already been considered ...
A test on Power or aarch might catch this one; where they normally
have larger pages.
Dave
> Could have mentioned that in the cover letter, yes.
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* [Buildroot] [PATCH/next 2/2] replace MESA_EGL_NO_X11_HEADERS hack with upstream EGL_NO_X11
From: Bernd Kuhls @ 2020-02-20 18:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20200220185917.37908-1-bernd.kuhls@t-online.de>
Mesa3d 20.0.0 deprecated MESA_EGL_NO_X11_HEADERS:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=6202a13b71e18dc31ba7e2f4ea915b67eacc1ddb
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
package/mali-t76x/egl.pc | 2 +-
package/mali-t76x/glesv2.pc | 2 +-
package/nvidia-driver/gl.pc | 2 +-
...e-forward-cflags-from-.pc-files-to-waffle-cflags.patch | 8 ++++----
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/package/mali-t76x/egl.pc b/package/mali-t76x/egl.pc
index 614b700d64..3de3c3ffd3 100644
--- a/package/mali-t76x/egl.pc
+++ b/package/mali-t76x/egl.pc
@@ -8,4 +8,4 @@ Description: ARM Mali implementation of EGL
Version: 1.5
Requires:
Libs: -L${libdir} -lEGL -lGLESv2
-Cflags: -I${includedir} -DMESA_EGL_NO_X11_HEADERS
+Cflags: -I${includedir} -DEGL_NO_X11
diff --git a/package/mali-t76x/glesv2.pc b/package/mali-t76x/glesv2.pc
index 5997eac63f..6521a3862d 100644
--- a/package/mali-t76x/glesv2.pc
+++ b/package/mali-t76x/glesv2.pc
@@ -8,4 +8,4 @@ Description: ARM Mali implementation of OpenGL ESv2
Version: 2.0
Requires:
Libs: -L${libdir} -lGLESv2 -lGLESv1_CM
-Cflags: -I${includedir} -DMESA_EGL_NO_X11_HEADERS
+Cflags: -I${includedir} -DEGL_NO_X11
diff --git a/package/nvidia-driver/gl.pc b/package/nvidia-driver/gl.pc
index d822763f57..d01f5d6944 100644
--- a/package/nvidia-driver/gl.pc
+++ b/package/nvidia-driver/gl.pc
@@ -7,5 +7,5 @@ Name: gl
Description: Nvidia OpenGL library
Version: 10.4.2
Libs: -L${libdir} -lGL -lm -lXext -lX11 -ldl
-Cflags: -I${includedir} -DMESA_EGL_NO_X11_HEADERS
+Cflags: -I${includedir} -DEGL_NO_X11
glx_tls: no
diff --git a/package/waffle/0002-cmake-forward-cflags-from-.pc-files-to-waffle-cflags.patch b/package/waffle/0002-cmake-forward-cflags-from-.pc-files-to-waffle-cflags.patch
index ffc1b5b8b1..126aa93300 100644
--- a/package/waffle/0002-cmake-forward-cflags-from-.pc-files-to-waffle-cflags.patch
+++ b/package/waffle/0002-cmake-forward-cflags-from-.pc-files-to-waffle-cflags.patch
@@ -4,12 +4,12 @@ Date: Sun, 24 Dec 2017 00:11:45 +0100
Subject: [PATCH] cmake: forward cflags from *.pc files to waffle cflags
When building mesa egl without x11 and gles2 the headers need a
-MESA_EGL_NO_X11_HEADERS define to avoid including X11 headers.
+EGL_NO_X11 define to avoid including X11 headers.
-This define MESA_EGL_NO_X11_HEADERS is lost while building waffle
-since CGLAGS defined by pc files are not used.
+This define EGL_NO_X11 is lost while building waffle
+since CFLAGS defined by pc files are not used.
-MESA_EGL_NO_X11_HEADERS is defined in CFLAGS from egl.pc.
+EGL_NO_X11 is defined in CFLAGS from egl.pc.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
--
2.20.1
^ permalink raw reply related
* [Buildroot] [PATCH/next 1/2] package/{mesa3d, mesa3d-headers}: bump version to 20.0.0
From: Bernd Kuhls @ 2020-02-20 18:59 UTC (permalink / raw)
To: buildroot
Updated license hash due to upstream commit:
https://cgit.freedesktop.org/mesa/mesa/commit/docs/license.html?&id=199572b65b7a03ffc887783e7f0f96f95bf1f99d
Added optional dependency to zstd present due to upstream commit:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=a8d941091f72923561a6c58b46ccb264b6a0e205
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
| 2 +-
package/mesa3d/mesa3d.hash | 8 ++++----
package/mesa3d/mesa3d.mk | 9 ++++++++-
3 files changed, 13 insertions(+), 6 deletions(-)
--git a/package/mesa3d-headers/mesa3d-headers.mk b/package/mesa3d-headers/mesa3d-headers.mk
index 7d428f2322..f4927a28c6 100644
--- a/package/mesa3d-headers/mesa3d-headers.mk
+++ b/package/mesa3d-headers/mesa3d-headers.mk
@@ -12,7 +12,7 @@ endif
# Not possible to directly refer to mesa3d variables, because of
# first/second expansion trickery...
-MESA3D_HEADERS_VERSION = 19.3.4
+MESA3D_HEADERS_VERSION = 20.0.0
MESA3D_HEADERS_SOURCE = mesa-$(MESA3D_HEADERS_VERSION).tar.xz
MESA3D_HEADERS_SITE = https://mesa.freedesktop.org/archive
MESA3D_HEADERS_DL_SUBDIR = mesa3d
diff --git a/package/mesa3d/mesa3d.hash b/package/mesa3d/mesa3d.hash
index 3237135b1c..e2ec6e625d 100644
--- a/package/mesa3d/mesa3d.hash
+++ b/package/mesa3d/mesa3d.hash
@@ -1,6 +1,6 @@
-# From https://lists.freedesktop.org/archives/mesa-announce/2020-February/000570.html
-sha256 1da467e6ae2799a517e242462331eafd29ae77d9872f3a845df81f7c308e8fe4 mesa-19.3.4.tar.xz
-sha512 2bbb3dc8f1d839f11fe12cc959393cd69607fa6714b2166b80299e0559d2d3b0ac38ed4e15ac3e5f472264eb24536d1901d350f7409f3a7e00d6f4ccbb2312fb mesa-19.3.4.tar.xz
+# From https://lists.freedesktop.org/archives/mesa-announce/2020-February/000572.html
+sha256 bb6db3e54b608d2536d4000b3de7dd3ae115fc114e8acbb5afff4b3bbed04b34 mesa-20.0.0.tar.xz
+sha512 3968820029434682fb6644947c76e12b6bb991a3d05cb519a6ea971ecc4aa9b21d03f84b9a452cc21cc77a7981db9e40dd2dfd3ea3dee85b3dd88a59b4842bbb mesa-20.0.0.tar.xz
# License
-sha256 d8d662974fc86e2e640362015e42de3fcc161d435a9f2111ecd8561412feca73 docs/license.html
+sha256 1ddae7da415352a5b5360ff3a9d7ecf23ba81408f62eeecce0011f32e3ef9da6 docs/license.html
diff --git a/package/mesa3d/mesa3d.mk b/package/mesa3d/mesa3d.mk
index 2a22d2fddc..9c9f38d17e 100644
--- a/package/mesa3d/mesa3d.mk
+++ b/package/mesa3d/mesa3d.mk
@@ -5,7 +5,7 @@
################################################################################
# When updating the version, please also update mesa3d-headers
-MESA3D_VERSION = 19.3.4
+MESA3D_VERSION = 20.0.0
MESA3D_SOURCE = mesa-$(MESA3D_VERSION).tar.xz
MESA3D_SITE = https://mesa.freedesktop.org/archive
MESA3D_LICENSE = MIT, SGI, Khronos
@@ -257,4 +257,11 @@ else
MESA3D_CONF_OPTS += -Dlmsensors=false
endif
+ifeq ($(BR2_PACKAGE_ZSTD),y)
+MESA3D_CONF_OPTS += -Dzstd=true
+MESA3D_DEPENDENCIES += zstd
+else
+MESA3D_CONF_OPTS += -Dzstd=false
+endif
+
$(eval $(meson-package))
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] hw: move timer_new from init() into realize() to avoid memleaks
From: Philippe Mathieu-Daudé @ 2020-02-20 18:51 UTC (permalink / raw)
To: Peter Maydell, Pan Nengyuan
Cc: zhanghailiang, Alistair Francis, QEMU Developers,
mav2-rk.cave-ayland, qemu-arm, qemu-ppc, Euler Robot,
Edgar E. Iglesias, David Gibson
In-Reply-To: <CAFEAcA_AxCVaAgho3g2q=kCifSdhz9Qi72eoVAM9gRjb3-_Sog@mail.gmail.com>
On 2/20/20 6:56 PM, Peter Maydell wrote:
> On Mon, 17 Feb 2020 at 03:22, <pannengyuan@huawei.com> wrote:
>>
>> From: Pan Nengyuan <pannengyuan@huawei.com>
>>
>> There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it.
>> Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize().
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
>
>> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
>> index 19e154b870..980eda7599 100644
>> --- a/hw/misc/mos6522.c
>> +++ b/hw/misc/mos6522.c
>> @@ -465,11 +465,15 @@ static void mos6522_reset(DeviceState *dev)
>> s->timers[0].frequency = s->frequency;
>> s->timers[0].latch = 0xffff;
>> set_counter(s, &s->timers[0], 0xffff);
>> - timer_del(s->timers[0].timer);
>> + if (s->timers[0].timer) {
>> + timer_del(s->timers[0].timer);
>> + }
>>
>> s->timers[1].frequency = s->frequency;
>> s->timers[1].latch = 0xffff;
>> - timer_del(s->timers[1].timer);
>> + if (s->timers[1].timer) {
>> + timer_del(s->timers[1].timer);
>> + }
>> }
>
> What code path calls a device 'reset' method on a device
> that has not yet been realized ? I wasn't expecting that
> to be valid...
This is not valid. What I understood while reviewing this patch is on
reset the timer is removed from the timers list. But this patch miss
setting timer = NULL in case the device is reset multiple times, here
can happen a NULL deref.
>
> thanks
> -- PMM
>
^ permalink raw reply
* Re: [PATCH] kcsan: Add option to allow watcher interruptions
From: Paul E. McKenney @ 2020-02-20 18:58 UTC (permalink / raw)
To: Marco Elver; +Cc: andreyknvl, glider, dvyukov, kasan-dev, linux-kernel
In-Reply-To: <20200220141551.166537-1-elver@google.com>
On Thu, Feb 20, 2020 at 03:15:51PM +0100, Marco Elver wrote:
> Add option to allow interrupts while a watchpoint is set up. This can be
> enabled either via CONFIG_KCSAN_INTERRUPT_WATCHER or via the boot
> parameter 'kcsan.interrupt_watcher=1'.
>
> Note that, currently not all safe per-CPU access primitives and patterns
> are accounted for, which could result in false positives. For example,
> asm-generic/percpu.h uses plain operations, which by default are
> instrumented. On interrupts and subsequent accesses to the same
> variable, KCSAN would currently report a data race with this option.
>
> Therefore, this option should currently remain disabled by default, but
> may be enabled for specific test scenarios.
>
> Signed-off-by: Marco Elver <elver@google.com>
Queued for review and testing, thank you!
> ---
>
> As an example, the first data race that this found:
>
> write to 0xffff88806b3324b8 of 4 bytes by interrupt on cpu 0:
> rcu_preempt_read_enter kernel/rcu/tree_plugin.h:353 [inline]
> __rcu_read_lock+0x3c/0x50 kernel/rcu/tree_plugin.h:373
> rcu_read_lock include/linux/rcupdate.h:599 [inline]
> cpuacct_charge+0x36/0x80 kernel/sched/cpuacct.c:347
> cgroup_account_cputime include/linux/cgroup.h:773 [inline]
> update_curr+0xe2/0x1d0 kernel/sched/fair.c:860
> enqueue_entity+0x130/0x5d0 kernel/sched/fair.c:4005
> enqueue_task_fair+0xb0/0x420 kernel/sched/fair.c:5260
> enqueue_task kernel/sched/core.c:1302 [inline]
> activate_task+0x6d/0x110 kernel/sched/core.c:1324
> ttwu_do_activate.isra.0+0x40/0x60 kernel/sched/core.c:2266
> ttwu_queue kernel/sched/core.c:2411 [inline]
> try_to_wake_up+0x3be/0x6c0 kernel/sched/core.c:2645
> wake_up_process+0x10/0x20 kernel/sched/core.c:2669
> hrtimer_wakeup+0x4c/0x60 kernel/time/hrtimer.c:1769
> __run_hrtimer kernel/time/hrtimer.c:1517 [inline]
> __hrtimer_run_queues+0x274/0x5f0 kernel/time/hrtimer.c:1579
> hrtimer_interrupt+0x22d/0x490 kernel/time/hrtimer.c:1641
> local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1119 [inline]
> smp_apic_timer_interrupt+0xdc/0x280 arch/x86/kernel/apic/apic.c:1144
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> delay_tsc+0x38/0xc0 arch/x86/lib/delay.c:68 <--- interrupt while delayed
> __delay arch/x86/lib/delay.c:161 [inline]
> __const_udelay+0x33/0x40 arch/x86/lib/delay.c:175
> __udelay+0x10/0x20 arch/x86/lib/delay.c:181
> kcsan_setup_watchpoint+0x17f/0x400 kernel/kcsan/core.c:428
> check_access kernel/kcsan/core.c:550 [inline]
> __tsan_read4+0xc6/0x100 kernel/kcsan/core.c:685 <--- Enter KCSAN runtime
> rcu_preempt_read_enter kernel/rcu/tree_plugin.h:353 [inline] <---+
> __rcu_read_lock+0x2a/0x50 kernel/rcu/tree_plugin.h:373 |
> rcu_read_lock include/linux/rcupdate.h:599 [inline] |
> lock_page_memcg+0x31/0x110 mm/memcontrol.c:1972 |
> |
> read to 0xffff88806b3324b8 of 4 bytes by task 6131 on cpu 0: |
> rcu_preempt_read_enter kernel/rcu/tree_plugin.h:353 [inline] ----+
> __rcu_read_lock+0x2a/0x50 kernel/rcu/tree_plugin.h:373
> rcu_read_lock include/linux/rcupdate.h:599 [inline]
> lock_page_memcg+0x31/0x110 mm/memcontrol.c:1972
>
> The writer is doing 'current->rcu_read_lock_nesting++'. The read is as
> vulnerable to compiler optimizations and would therefore conclude this
> is a valid data race.
Heh! That one is a fun one! It is on a very hot fastpath. READ_ONCE()
and WRITE_ONCE() are likely to be measurable at the system level.
Thoughts on other options?
Thanx, Paul
> ---
> kernel/kcsan/core.c | 30 ++++++++----------------------
> lib/Kconfig.kcsan | 11 +++++++++++
> 2 files changed, 19 insertions(+), 22 deletions(-)
>
> diff --git a/kernel/kcsan/core.c b/kernel/kcsan/core.c
> index 589b1e7f0f253..43eb5f850c68e 100644
> --- a/kernel/kcsan/core.c
> +++ b/kernel/kcsan/core.c
> @@ -21,6 +21,7 @@ static bool kcsan_early_enable = IS_ENABLED(CONFIG_KCSAN_EARLY_ENABLE);
> static unsigned int kcsan_udelay_task = CONFIG_KCSAN_UDELAY_TASK;
> static unsigned int kcsan_udelay_interrupt = CONFIG_KCSAN_UDELAY_INTERRUPT;
> static long kcsan_skip_watch = CONFIG_KCSAN_SKIP_WATCH;
> +static bool kcsan_interrupt_watcher = IS_ENABLED(CONFIG_KCSAN_INTERRUPT_WATCHER);
>
> #ifdef MODULE_PARAM_PREFIX
> #undef MODULE_PARAM_PREFIX
> @@ -30,6 +31,7 @@ module_param_named(early_enable, kcsan_early_enable, bool, 0);
> module_param_named(udelay_task, kcsan_udelay_task, uint, 0644);
> module_param_named(udelay_interrupt, kcsan_udelay_interrupt, uint, 0644);
> module_param_named(skip_watch, kcsan_skip_watch, long, 0644);
> +module_param_named(interrupt_watcher, kcsan_interrupt_watcher, bool, 0444);
>
> bool kcsan_enabled;
>
> @@ -354,7 +356,7 @@ kcsan_setup_watchpoint(const volatile void *ptr, size_t size, int type)
> unsigned long access_mask;
> enum kcsan_value_change value_change = KCSAN_VALUE_CHANGE_MAYBE;
> unsigned long ua_flags = user_access_save();
> - unsigned long irq_flags;
> + unsigned long irq_flags = 0;
>
> /*
> * Always reset kcsan_skip counter in slow-path to avoid underflow; see
> @@ -370,26 +372,9 @@ kcsan_setup_watchpoint(const volatile void *ptr, size_t size, int type)
> goto out;
> }
>
> - /*
> - * Disable interrupts & preemptions to avoid another thread on the same
> - * CPU accessing memory locations for the set up watchpoint; this is to
> - * avoid reporting races to e.g. CPU-local data.
> - *
> - * An alternative would be adding the source CPU to the watchpoint
> - * encoding, and checking that watchpoint-CPU != this-CPU. There are
> - * several problems with this:
> - * 1. we should avoid stealing more bits from the watchpoint encoding
> - * as it would affect accuracy, as well as increase performance
> - * overhead in the fast-path;
> - * 2. if we are preempted, but there *is* a genuine data race, we
> - * would *not* report it -- since this is the common case (vs.
> - * CPU-local data accesses), it makes more sense (from a data race
> - * detection point of view) to simply disable preemptions to ensure
> - * as many tasks as possible run on other CPUs.
> - *
> - * Use raw versions, to avoid lockdep recursion via IRQ flags tracing.
> - */
> - raw_local_irq_save(irq_flags);
> + if (!kcsan_interrupt_watcher)
> + /* Use raw to avoid lockdep recursion via IRQ flags tracing. */
> + raw_local_irq_save(irq_flags);
>
> watchpoint = insert_watchpoint((unsigned long)ptr, size, is_write);
> if (watchpoint == NULL) {
> @@ -524,7 +509,8 @@ kcsan_setup_watchpoint(const volatile void *ptr, size_t size, int type)
>
> kcsan_counter_dec(KCSAN_COUNTER_USED_WATCHPOINTS);
> out_unlock:
> - raw_local_irq_restore(irq_flags);
> + if (!kcsan_interrupt_watcher)
> + raw_local_irq_restore(irq_flags);
> out:
> user_access_restore(ua_flags);
> }
> diff --git a/lib/Kconfig.kcsan b/lib/Kconfig.kcsan
> index ba9268076cfbc..0f1447ff8f558 100644
> --- a/lib/Kconfig.kcsan
> +++ b/lib/Kconfig.kcsan
> @@ -101,6 +101,17 @@ config KCSAN_SKIP_WATCH_RANDOMIZE
> KCSAN_WATCH_SKIP. If false, the chosen value is always
> KCSAN_WATCH_SKIP.
>
> +config KCSAN_INTERRUPT_WATCHER
> + bool "Interruptible watchers"
> + help
> + If enabled, a task that set up a watchpoint may be interrupted while
> + delayed. This option will allow KCSAN to detect races between
> + interrupted tasks and other threads of execution on the same CPU.
> +
> + Currently disabled by default, because not all safe per-CPU access
> + primitives and patterns may be accounted for, and therefore could
> + result in false positives.
> +
> config KCSAN_REPORT_ONCE_IN_MS
> int "Duration in milliseconds, in which any given race is only reported once"
> default 3000
> --
> 2.25.0.265.gbab2e86ba0-goog
>
^ permalink raw reply
* [PATCH] net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII
From: Matthias Brugger @ 2020-02-20 18:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200220163630.29806-1-nsaenzjulienne@suse.de>
On 20/02/2020 17:36, Nicolas Saenz Julienne wrote:
> As per Linux's driver, ID_MODE_DIS is only set when the PHY interface is
> RGMII. Don't enable it for the rest of setups.
>
> This has been seen to misconfigure RPi4's PHY when booting Linux.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
> drivers/net/bcmgenet.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
> index 8f4848aec6..e971b556ac 100644
> --- a/drivers/net/bcmgenet.c
> +++ b/drivers/net/bcmgenet.c
> @@ -448,7 +448,10 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv *priv)
> }
>
> clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
> - RGMII_LINK | RGMII_MODE_EN | ID_MODE_DIS);
> + RGMII_LINK | RGMII_MODE_EN);
> +
> + if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
> + setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
Is this given because by different DTS? Shouldn't that be uniform on the RPi4?
BTW Joe, will you take patches for this driver through your branch? For now I
delegated it to me, but I'm fine either way.
Regards,
Matthias
>
> writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
>
>
^ permalink raw reply
* Re: [RFC PATCH] iommu/dma: Allow drivers to reserve an iova range
From: Pratik Patel @ 2020-02-20 18:57 UTC (permalink / raw)
To: Will Deacon
Cc: isaacm, Robin Murphy, Christoph Hellwig, linux-kernel, Liam Mark,
iommu, kernel-team
In-Reply-To: <20200220084552.GB11827@willie-the-truck>
On 02/20 08:45 am, Will Deacon wrote:
> On Wed, Feb 19, 2020 at 12:06:28PM -0800, isaacm@codeaurora.org wrote:
> > On 2020-02-19 03:15, Will Deacon wrote:
> > > On Tue, Feb 18, 2020 at 05:57:18PM -0800, isaacm@codeaurora.org wrote:
> > > > Does this mean that the driver should be managing the IOVA space and
> > > > mappings for this device using the IOMMU API? If so, is the
> > > > rationale for
> > > > this because the device driver can have the information of what IOVA
> > > > ranges
> > > > can and cannot be used? Shouldn't there be a generic way of
> > > > informing an
> > > > IOMMU driver about these reserved ranges? Perhaps through a device
> > > > tree
> > > > property, instead of deferring this type of management to the driver?
> > >
> > > Before we dive into designing that, can you please clarify whether the
> > > reserved IOVA range applies to all DMA masters mastering through a
> > > particular SMMU, or whether it's just about one specific master? I was
> > > assuming the former, but wanted to be sure.
> > >
> > This situation currently applies to one master.
>
> Interesting. Is it problematic if the range is reserved for all masters
> sharing that SMMU?
>
Yes, that would be an overkill. It certainly is useful and in
some cases quite helpful to not waste that range of IOVA space for
other masters on the same SMMU that can use it.
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] tcg: gdbstub: Fix single-step issue on arm target
From: Philippe Mathieu-Daudé @ 2020-02-20 18:55 UTC (permalink / raw)
To: Laurent Vivier, Changbin Du, alex.bennee; +Cc: qemu-devel
In-Reply-To: <2f66143c-daa8-2f1d-0593-424791d81fd0@vivier.eu>
On 2/20/20 7:06 PM, Laurent Vivier wrote:
> Le 20/02/2020 à 18:47, Philippe Mathieu-Daudé a écrit :
>> On 2/20/20 4:58 PM, Changbin Du wrote:
>>> Recently when debugging an arm32 system on qemu, I found sometimes the
>>> single-step command (stepi) is not working. This can be reproduced by
>>> below steps:
>>> 1) start qemu-system-arm -s -S .. and wait for gdb connection.
>>> 2) start gdb and connect to qemu. In my case, gdb gets a wrong value
>>> (0x60) for PC.
>>> 3) After connected, type 'stepi' and expect it will stop at next ins.
>>>
>>> But, it has never stopped. This because:
>>> 1) We doesn't report ‘vContSupported’ feature to gdb explicitly and gdb
>>> think we do not support it. In this case, gdb use a software
>>> breakpoint
>>> to emulate single-step.
>>> 2) Since gdb gets a wrong initial value of PC, then gdb inserts a
>>> breakpoint to wrong place (PC+4).
>>>
>>> Since we do support ‘vContSupported’ query command, so let's tell gdb
>>> that
>>> we support it.
>>>
>>> Before this change, gdb send below 'Z0' packet to implement single-step:
>>> gdb_handle_packet: Z0,4,4
>>>
>>> After this change, gdb send "vCont;s.." which is expected:
>>> gdb_handle_packet: vCont?
>>> put_packet: vCont;c;C;s;S
>>> gdb_handle_packet: vCont;s:p1.1;c:p1.-1
>>
>> You actually fixed this for all architectures :)
>>
>> This has been annoying me on MIPS since more than a year...
>
> The problem started with an update of QEMU or of GDB?
>
> At one point it seemed to work, so what happened?
I'd say gdb. I can try different combinations of QEMU/gdb but I won't do
that soon.
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/mgag200: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 18:56 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, virtualization, kraxel, alexander.deucher,
spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-4-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
> The mgag200 driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 61 ++------------------------
> 2 files changed, 3 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
> index aa32aad222c2..9bb9e8e14539 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> @@ -95,7 +95,6 @@
> #define MATROX_DPMS_CLEARED (-1)
>
> #define to_mga_crtc(x) container_of(x, struct mga_crtc, base)
> -#define to_mga_encoder(x) container_of(x, struct mga_encoder, base)
> #define to_mga_connector(x) container_of(x, struct mga_connector, base)
>
> struct mga_crtc {
> @@ -110,12 +109,6 @@ struct mga_mode_info {
> struct mga_crtc *crtc;
> };
>
> -struct mga_encoder {
> - struct drm_encoder base;
> - int last_dpms;
> -};
> -
> -
> struct mga_i2c_chan {
> struct i2c_adapter adapter;
> struct drm_device *dev;
Any particular reason why the drm_encoder is not embedded in struct
mga_device?
I found it more elegant - like you did it for ast in the previous patch.
I also noted there is one more unused "last_dpms" - but it is outside
the scope of this patch to remove it.
Sam
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 62a8e9ccb16d..957ea1057b6c 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -15,6 +15,7 @@
> #include <drm/drm_fourcc.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "mgag200_drv.h"
>
> @@ -1449,72 +1450,16 @@ static void mga_crtc_init(struct mga_device *mdev)
> drm_crtc_helper_add(&mga_crtc->base, &mga_helper_funcs);
> }
>
> -/*
> - * The encoder comes after the CRTC in the output pipeline, but before
> - * the connector. It's responsible for ensuring that the digital
> - * stream is appropriately converted into the output format. Setup is
> - * very simple in this case - all we have to do is inform qemu of the
> - * colour depth in order to ensure that it displays appropriately
> - */
> -
> -/*
> - * These functions are analagous to those in the CRTC code, but are intended
> - * to handle any encoder-specific limitations
> - */
> -static void mga_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> -
> -}
> -
> -static void mga_encoder_dpms(struct drm_encoder *encoder, int state)
> -{
> - return;
> -}
> -
> -static void mga_encoder_prepare(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_commit(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_destroy(struct drm_encoder *encoder)
> -{
> - struct mga_encoder *mga_encoder = to_mga_encoder(encoder);
> - drm_encoder_cleanup(encoder);
> - kfree(mga_encoder);
> -}
> -
> -static const struct drm_encoder_helper_funcs mga_encoder_helper_funcs = {
> - .dpms = mga_encoder_dpms,
> - .mode_set = mga_encoder_mode_set,
> - .prepare = mga_encoder_prepare,
> - .commit = mga_encoder_commit,
> -};
> -
> -static const struct drm_encoder_funcs mga_encoder_encoder_funcs = {
> - .destroy = mga_encoder_destroy,
> -};
> -
> static struct drm_encoder *mga_encoder_init(struct drm_device *dev)
> {
> struct drm_encoder *encoder;
> - struct mga_encoder *mga_encoder;
>
> - mga_encoder = kzalloc(sizeof(struct mga_encoder), GFP_KERNEL);
> - if (!mga_encoder)
> + encoder = drm_simple_encoder_create(dev, DRM_MODE_ENCODER_DAC);
> + if (IS_ERR(encoder))
> return NULL;
>
> - encoder = &mga_encoder->base;
> encoder->possible_crtcs = 0x1;
>
> - drm_encoder_init(dev, encoder, &mga_encoder_encoder_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> - drm_encoder_helper_add(encoder, &mga_encoder_helper_funcs);
> -
> return encoder;
> }
>
> --
> 2.25.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/4] drm/mgag200: Use simple encoder
From: Sam Ravnborg @ 2020-02-20 18:56 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: airlied, dri-devel, maarten.lankhorst, mripard, virtualization,
noralf, daniel, alexander.deucher, spice-devel, emil.velikov
In-Reply-To: <20200218084815.2137-4-tzimmermann@suse.de>
Hi Thomas.
On Tue, Feb 18, 2020 at 09:48:14AM +0100, Thomas Zimmermann wrote:
> The mgag200 driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> v2:
> * rebase onto new simple-encoder interface
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.h | 7 ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 61 ++------------------------
> 2 files changed, 3 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h b/drivers/gpu/drm/mgag200/mgag200_drv.h
> index aa32aad222c2..9bb9e8e14539 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.h
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
> @@ -95,7 +95,6 @@
> #define MATROX_DPMS_CLEARED (-1)
>
> #define to_mga_crtc(x) container_of(x, struct mga_crtc, base)
> -#define to_mga_encoder(x) container_of(x, struct mga_encoder, base)
> #define to_mga_connector(x) container_of(x, struct mga_connector, base)
>
> struct mga_crtc {
> @@ -110,12 +109,6 @@ struct mga_mode_info {
> struct mga_crtc *crtc;
> };
>
> -struct mga_encoder {
> - struct drm_encoder base;
> - int last_dpms;
> -};
> -
> -
> struct mga_i2c_chan {
> struct i2c_adapter adapter;
> struct drm_device *dev;
Any particular reason why the drm_encoder is not embedded in struct
mga_device?
I found it more elegant - like you did it for ast in the previous patch.
I also noted there is one more unused "last_dpms" - but it is outside
the scope of this patch to remove it.
Sam
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index 62a8e9ccb16d..957ea1057b6c 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -15,6 +15,7 @@
> #include <drm/drm_fourcc.h>
> #include <drm/drm_plane_helper.h>
> #include <drm/drm_probe_helper.h>
> +#include <drm/drm_simple_kms_helper.h>
>
> #include "mgag200_drv.h"
>
> @@ -1449,72 +1450,16 @@ static void mga_crtc_init(struct mga_device *mdev)
> drm_crtc_helper_add(&mga_crtc->base, &mga_helper_funcs);
> }
>
> -/*
> - * The encoder comes after the CRTC in the output pipeline, but before
> - * the connector. It's responsible for ensuring that the digital
> - * stream is appropriately converted into the output format. Setup is
> - * very simple in this case - all we have to do is inform qemu of the
> - * colour depth in order to ensure that it displays appropriately
> - */
> -
> -/*
> - * These functions are analagous to those in the CRTC code, but are intended
> - * to handle any encoder-specific limitations
> - */
> -static void mga_encoder_mode_set(struct drm_encoder *encoder,
> - struct drm_display_mode *mode,
> - struct drm_display_mode *adjusted_mode)
> -{
> -
> -}
> -
> -static void mga_encoder_dpms(struct drm_encoder *encoder, int state)
> -{
> - return;
> -}
> -
> -static void mga_encoder_prepare(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_commit(struct drm_encoder *encoder)
> -{
> -}
> -
> -static void mga_encoder_destroy(struct drm_encoder *encoder)
> -{
> - struct mga_encoder *mga_encoder = to_mga_encoder(encoder);
> - drm_encoder_cleanup(encoder);
> - kfree(mga_encoder);
> -}
> -
> -static const struct drm_encoder_helper_funcs mga_encoder_helper_funcs = {
> - .dpms = mga_encoder_dpms,
> - .mode_set = mga_encoder_mode_set,
> - .prepare = mga_encoder_prepare,
> - .commit = mga_encoder_commit,
> -};
> -
> -static const struct drm_encoder_funcs mga_encoder_encoder_funcs = {
> - .destroy = mga_encoder_destroy,
> -};
> -
> static struct drm_encoder *mga_encoder_init(struct drm_device *dev)
> {
> struct drm_encoder *encoder;
> - struct mga_encoder *mga_encoder;
>
> - mga_encoder = kzalloc(sizeof(struct mga_encoder), GFP_KERNEL);
> - if (!mga_encoder)
> + encoder = drm_simple_encoder_create(dev, DRM_MODE_ENCODER_DAC);
> + if (IS_ERR(encoder))
> return NULL;
>
> - encoder = &mga_encoder->base;
> encoder->possible_crtcs = 0x1;
>
> - drm_encoder_init(dev, encoder, &mga_encoder_encoder_funcs,
> - DRM_MODE_ENCODER_DAC, NULL);
> - drm_encoder_helper_add(encoder, &mga_encoder_helper_funcs);
> -
> return encoder;
> }
>
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges
From: Florian Fainelli @ 2020-02-20 18:56 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Vladimir Oltean, Andrew Lunn, Heiner Kallweit, Ido Schimmel,
Vivien Didelot, David S. Miller, Ivan Vecera, Jakub Kicinski,
Jiri Pirko, netdev
In-Reply-To: <20200219231528.GS25745@shell.armlinux.org.uk>
On 2/19/20 3:15 PM, Russell King - ARM Linux admin wrote:
> On Wed, Feb 19, 2020 at 11:18:17AM -0800, Florian Fainelli wrote:
>> On 2/19/20 10:52 AM, Vladimir Oltean wrote:
>>> On Wed, 19 Feb 2020 at 02:02, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>>
>>>> Why not just revert 2ea7a679ca2abd251c1ec03f20508619707e1749 ("net: dsa:
>>>> Don't add vlans when vlan filtering is disabled")? If a driver wants to
>>>> veto the programming of VLANs while it has ports enslaved to a bridge
>>>> that does not have VLAN filtering, it should have enough information to
>>>> not do that operation.
>>>> --
>>>> Florian
>>>
>>> It would be worth mentioning that for sja1105 and hypothetical other
>>> users of DSA_TAG_PROTO_8021Q, DSA doing that automatically was
>>> helpful. VLAN manipulations are still being done from tag_8021q.c for
>>> the purpose of DSA tagging, but the fact that the VLAN EtherType is
>>> not 0x8100 means that from the perspective of real VLAN traffic, the
>>> switch is VLAN unaware. DSA was the easiest place to disseminate
>>> between VLAN requests of its own and VLAN requests coming from
>>> switchdev.
>>> Without that logic in DSA, a vlan-unaware bridge would be able to
>>> destroy the configuration done for source port decoding.
>>> Just saying - with enough logic in .port_vlan_prepare, I should still
>>> be able to accept only what's whitelisted to work for tagging, and
>>> then it won't matter who issued that VLAN command.
>>
>> I suppose I am fine with Russell's approach, but maybe its meaning
>> should be reversed, that is, you get VLAN objects notifications by
>> default for a VLAN unaware bridge and if you do set a specific
>> dsa_switch flag, then you do not get those.
>
> If we reverse it, I'll need someone to tell me which DSA switches
> should not get the vlan object notifications. Maybe also in that
> case, we should deny the ability to toggle the state of
> vlan_filtering as well?
>
Let's get your patch series merged. If you re-spin while addressing
Vivien's comment not to use the term "vtu", I think I would be fine with
the current approach of having to go after each driver and enabling them
where necessary.
Thanks
--
Florian
^ permalink raw reply
* [PATCH] media: staging: rkisp1: capture: remove support to userptr memory
From: Dafna Hirschfeld @ 2020-02-20 18:56 UTC (permalink / raw)
To: linux-media
Cc: dafna.hirschfeld, helen.koike, ezequiel, hverkuil, kernel, dafna3,
sakari.ailus, linux-rockchip, mchehab
The dma_contig memory operations which is used by the capture
should not support userptr. Therefore remove it.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
---
drivers/staging/media/rkisp1/rkisp1-capture.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/rkisp1/rkisp1-capture.c b/drivers/staging/media/rkisp1/rkisp1-capture.c
index 5f97af5cd95f..a006cd03228d 100644
--- a/drivers/staging/media/rkisp1/rkisp1-capture.c
+++ b/drivers/staging/media/rkisp1/rkisp1-capture.c
@@ -1349,7 +1349,7 @@ static int rkisp1_register_capture(struct rkisp1_capture *cap)
q = &node->buf_queue;
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
- q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_USERPTR;
+ q->io_modes = VB2_MMAP | VB2_DMABUF;
q->drv_priv = cap;
q->ops = &rkisp1_vb2_ops;
q->mem_ops = &vb2_dma_contig_memops;
--
2.17.1
^ permalink raw reply related
* Re: [meta-ti] am437x-evm zeus image
From: Denys Dmytriyenko @ 2020-02-20 18:55 UTC (permalink / raw)
To: Daniel Ammann; +Cc: meta-ti
In-Reply-To: <b7af4338-6409-457d-5bf4-173ebcb92b38@bytesatwork.ch>
On Thu, Feb 20, 2020 at 11:21:46AM +0100, Daniel Ammann wrote:
> Hi Denys
>
> Thanks for the answer.
>
> My build configuration looks like this:
>
> Build Configuration:
> BB_VERSION = "1.44.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING = "universal"
> TARGET_SYS = "arm-poky-linux-gnueabi"
Ah, "poky" toolchain, which doesn't use "gnueabihf" suffix... Probably need
the same hack as for the generic "oe" toolchain - I'll take a look.
> MACHINE = "am437x-evm"
> DISTRO = "poky"
> DISTRO_VERSION = "3.0.2"
> TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard"
> TARGET_FPU = "hard"
> meta
> meta-poky
> meta-yocto-bsp = "zeus:5e1f52edb7a9f790fb6cb5d96502f3690267c1b1"
> meta-oe
> meta-networking
> meta-python = "zeus:bb65c27a772723dfe2c15b5e1b27bcc1a1ed884c"
> meta-ti = "zeus:19a73c96bd05a74711a36a61077e8a7b88b55c63"
>
> See below for the error messgage.
>
> Thanks and kind regards
>
> Daniel
>
>
> ERROR: ti-sgx-ddk-km-1.17.4948957-r3v do_compile: oe_runmake failed
> ERROR: ti-sgx-ddk-km-1.17.4948957-r3v do_compile: Execution of '/home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v/temp/run.do_compile.19460' failed with exit code 1:
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/amba: Is a directory
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/avf: Is a directory
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/bcma: Is a directory
> .
> .
> .
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/unaligned: Is a directory
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/usb: Is a directory
> grep: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source/include/linux/wimax: Is a directory
> ../config/compiler.mk:96: host gcc
> ../config/compiler.mk:185: target arm-poky-linux-gnueabi-gcc -mno-thumb-interwork -marm -fuse-ld=bfd -fmacro-prefix-map=/home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v=/usr/src/debug/ti-sgx-ddk-km/1.17.4948957-r3v -fdebug-prefix-map=/home/daniel/workspace/reference/am335x-evm-poky
> /build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v=/usr/src/debug/ti-sgx-ddk-km/1.17.4948957-r3v -fdebug-prefix-map=/home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v/recipe-sysroot= -fdebug-prefix-map=/home/daniel/workspace/reference/am3
> 35x-evm-poky/build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v/recipe-sysroot-native= -fdebug-prefix-map=/home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work-shared/am437x-evm/kernel-source=/usr/src/kernel
> ******* Multiarch build: no
> ******* Primary arch: target_armel
> ******* Secondary arch: none
> ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild may fail.
> eurasiacon/build/linux2/toplevel.mk:230: eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or directory
> make[1]: *** No rule to make target 'eurasiacon/build/linux2/moduledefs/target_armel.mk'. Stop.
> make: *** [../config/core.mk:789: build] Error 2
> WARNING: exit code 1 from a shell command.
>
> ERROR: Logfile of failure stored in: /home/daniel/workspace/reference/am335x-evm-poky/build/tmp/work/am437x_evm-poky-linux-gnueabi/ti-sgx-ddk-km/1.17.4948957-r3v/temp/log.do_compile.19460
>
>
>
> On 2/19/20 8:00 PM, Denys Dmytriyenko wrote:
> >Daniel,
> >
> >You are not providing any useful info, such as error messages or logs.
> >
> >In general, yes, am437x-evm on Zeus is ready and has been building fine in
> >many different configurations.
> >
> >Denys
> >
> >
> >On Wed, Feb 19, 2020 at 11:27:55AM +0100, Daniel Ammann wrote:
> >>Hi all
> >>
> >>I'm trying to build a zeus image for am437x-evm. How do I go about that? Is
> >>meta-ti branch zeus ready yet?
> >>
> >>First, I tried a simple poky build with meta-openembedded and meta-ti, building
> >>core-image-base. But compiling of ti-sgx-ddk-km fails.
> >>
> >>Then I followed the instructions in the arago wiki [1], but the build fails
> >>with qtbase because qtbase doesn't run configure successfully.
> >>
> >>What is the recommended way to compile a development image? The goal is to compile
> >>a qt5 application with qtwebengine that needs eglfs support.
> >>
> >>[1] http://arago-project.org/wiki/index.php/Setting_Up_Build_Environment
> >>
> >>Thanks and kind regards
> >>
> >>Daniel
>
> --
> bytes at work
> Technoparkstrasse 7
> CH-8406 Winterthur
> Switzerland
>
> phone: +41 52 550 50 67
^ permalink raw reply
* Re: BUG: git clean -d cannot remove files from read-only directories
From: Adam Milazzo @ 2020-02-20 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
> It is how UNIX-like filesystem works, isn't it?
Sure, but it doesn't have to be how "git clean -d" works. In particular, "git clean -ffd" could be more forceful, or there could be another option or a third level of force beyond the current two levels.
It really comes back to this question: "How can I avoid the failure, given that I am running 'git clean' from a script and not interactively?" The only answer I could find that's not unreasonable is to parse the text output of 'git status -s' to find the untracked directories and then run 'chmod -R u+w' on each of those directories before running 'git clean -d'." I can do that, but I still think a "force" (or other) flag that really forces the cleanup would be preferable, especially given that this isn't a completely idiosyncratic scenario but one that will happen more and more as go modules are adopted (unless go is changed to stop putting them in read-only directories).
^ permalink raw reply
* RE: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
From: Ertman, David M @ 2020-02-20 18:55 UTC (permalink / raw)
To: Greg KH, Jason Gunthorpe
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, nhorman@redhat.com,
sassmann@redhat.com, parav@mellanox.com, galpress@amazon.com,
selvin.xavier@broadcom.com, sriharsha.basavapatna@broadcom.com,
benve@cisco.com, bharat@chelsio.com, xavier.huwei@huawei.com,
yishaih@mellanox.com, leonro@mellanox.com, mkalderon@marvell.com,
aditr@vmware.com, Patil, Kiran, Bowers, AndrewX
In-Reply-To: <20200214204500.GC4086224@kroah.com>
> -----Original Message-----
> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Friday, February 14, 2020 12:45 PM
> To: Jason Gunthorpe <jgg@ziepe.ca>
> Cc: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>; davem@davemloft.net;
> Ertman, David M <david.m.ertman@intel.com>; netdev@vger.kernel.org;
> linux-rdma@vger.kernel.org; nhorman@redhat.com;
> sassmann@redhat.com; parav@mellanox.com; galpress@amazon.com;
> selvin.xavier@broadcom.com; sriharsha.basavapatna@broadcom.com;
> benve@cisco.com; bharat@chelsio.com; xavier.huwei@huawei.com;
> yishaih@mellanox.com; leonro@mellanox.com; mkalderon@marvell.com;
> aditr@vmware.com; Patil, Kiran <kiran.patil@intel.com>; Bowers, AndrewX
> <andrewx.bowers@intel.com>
> Subject: Re: [RFC PATCH v4 01/25] virtual-bus: Implementation of Virtual Bus
>
> On Fri, Feb 14, 2020 at 04:34:55PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 14, 2020 at 09:02:40AM -0800, Greg KH wrote:
> > > > + put_device(&vdev->dev);
> > > > + ida_simple_remove(&virtbus_dev_ida, vdev->id);
> > >
> > > You need to do this before put_device().
> >
> > Shouldn't it be in the release function? The ida index should not be
> > re-used until the kref goes to zero..
The IDA should not be reused until the virtbus_device is unregistered. We
don't want another device with the same name and same IDA to be registered,
so the IDA has to remain unique until the device is unregistered, that is why
I am moving it to before put_device, but remember, this index is just to
ensure unique naming among the devices registered on the bus. There could
(and will) be several foo_rdma devices created (one per PF) and we need to keep
them all straight.
>
> Doesn't really matter, once you have unregistered it, you can reuse it.
> But yes, putting it in release() is the safest thing to do.
>
> > > > +struct virtbus_device {
> > > > + struct device dev;
> > > > + const char *name;
> > > > + void (*release)(struct virtbus_device *);
> > > > + int id;
> > > > + const struct virtbus_dev_id *matched_element;
> > > > +};
> > >
> > > Any reason you need to make "struct virtbus_device" a public structure
> > > at all?
> >
> > The general point of this scheme is to do this in a public header:
> >
> > +struct iidc_virtbus_object {
> > + struct virtbus_device vdev;
> > + struct iidc_peer_dev *peer_dev;
> > +};
> >
> > And then this when the driver binds:
>
> Ah, yes, nevermind, I missed that.
>
> greg k-h
-DaveE
^ permalink raw reply
* [PATCH v2] ASoC: tas2562: Add support for digital volume control
From: Dan Murphy @ 2020-02-20 18:49 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai; +Cc: alsa-devel, linux-kernel, Dan Murphy
Add support for digital volume control. There is no dedicated register
for volume control but instead there are 4. The values of the registers
are determined with exponential floating point math.
So a table was created with register values for 2dB step increments
from -110dB to 0dB.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v2 - Fix init values to lower volume CFG4 is the LSB and CFG1 is MSB
sound/soc/codecs/tas2562.c | 94 ++++++++++++++++++++++++++++++++++++++
sound/soc/codecs/tas2562.h | 6 ++-
2 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/tas2562.c b/sound/soc/codecs/tas2562.c
index b2682c2360b6..92e4bf34b35c 100644
--- a/sound/soc/codecs/tas2562.c
+++ b/sound/soc/codecs/tas2562.c
@@ -26,6 +26,24 @@
#define TAS2562_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE |\
SNDRV_PCM_FORMAT_S32_LE)
+/* DVC equation involves floating point math
+ * round(10^(volume in dB/20)*2^30)
+ * so create a lookup table for 2dB step
+ */
+static const unsigned int float_vol_db_lookup[] = {
+0x00000d43, 0x000010b2, 0x00001505, 0x00001a67, 0x00002151,
+0x000029f1, 0x000034cd, 0x00004279, 0x000053af, 0x0000695b,
+0x0000695b, 0x0000a6fa, 0x0000d236, 0x000108a4, 0x00014d2a,
+0x0001a36e, 0x00021008, 0x000298c0, 0x000344df, 0x00041d8f,
+0x00052e5a, 0x000685c8, 0x00083621, 0x000a566d, 0x000d03a7,
+0x0010624d, 0x0014a050, 0x0019f786, 0x0020b0bc, 0x0029279d,
+0x0033cf8d, 0x004139d3, 0x00521d50, 0x00676044, 0x0082248a,
+0x00a3d70a, 0x00ce4328, 0x0103ab3d, 0x0146e75d, 0x019b8c27,
+0x02061b89, 0x028c423f, 0x03352529, 0x0409c2b0, 0x05156d68,
+0x080e9f96, 0x0a24b062, 0x0cc509ab, 0x10137987, 0x143d1362,
+0x197a967f, 0x2013739e, 0x28619ae9, 0x32d64617, 0x40000000
+};
+
struct tas2562_data {
struct snd_soc_component *component;
struct gpio_desc *sdz_gpio;
@@ -34,6 +52,7 @@ struct tas2562_data {
struct i2c_client *client;
int v_sense_slot;
int i_sense_slot;
+ int volume_lvl;
};
static int tas2562_set_bias_level(struct snd_soc_component *component,
@@ -334,6 +353,22 @@ static int tas2562_codec_probe(struct snd_soc_component *component)
if (ret < 0)
return ret;
+ /* Set the Digital volume to -110dB */
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG4, 0x43);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG3, 0x0d);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG2, 0x00);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG1, 0x00);
+ if (ret)
+ return ret;
+
+ tas2562->volume_lvl = 0;
+
return 0;
}
@@ -414,6 +449,50 @@ static int tas2562_dac_event(struct snd_soc_dapm_widget *w,
return 0;
}
+static int tas2562_volume_control_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component = snd_soc_kcontrol_component(kcontrol);
+ struct tas2562_data *tas2562 = snd_soc_component_get_drvdata(component);
+
+ ucontrol->value.integer.value[0] = tas2562->volume_lvl;
+ return 0;
+}
+
+static int tas2562_volume_control_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component = snd_soc_kcontrol_component(kcontrol);
+ struct tas2562_data *tas2562 = snd_soc_component_get_drvdata(component);
+ int ret;
+ u32 reg_val;
+
+ reg_val = float_vol_db_lookup[ucontrol->value.integer.value[0]/2];
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG4,
+ (reg_val & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG3,
+ ((reg_val >> 8) & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG2,
+ ((reg_val >> 16) & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG1,
+ ((reg_val >> 24) & 0xff));
+ if (ret)
+ return ret;
+
+ tas2562->volume_lvl = ucontrol->value.integer.value[0];
+
+ return ret;
+}
+
+/* Digital Volume Control. From 0 dB to -110 dB in 1 dB steps */
+static const DECLARE_TLV_DB_SCALE(dvc_tlv, -11000, 100, 0);
+
static DECLARE_TLV_DB_SCALE(tas2562_dac_tlv, 850, 50, 0);
static const struct snd_kcontrol_new isense_switch =
@@ -427,6 +506,17 @@ static const struct snd_kcontrol_new vsense_switch =
static const struct snd_kcontrol_new tas2562_snd_controls[] = {
SOC_SINGLE_TLV("Amp Gain Volume", TAS2562_PB_CFG1, 0, 0x1c, 0,
tas2562_dac_tlv),
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .name = "Digital Volume Control",
+ .index = 0,
+ .tlv.p = dvc_tlv,
+ .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .info = snd_soc_info_volsw,
+ .get = tas2562_volume_control_get,
+ .put = tas2562_volume_control_put,
+ .private_value = SOC_SINGLE_VALUE(TAS2562_DVC_CFG1, 0, 110, 0, 0) ,
+ },
};
static const struct snd_soc_dapm_widget tas2562_dapm_widgets[] = {
@@ -517,6 +607,10 @@ static const struct reg_default tas2562_reg_defaults[] = {
{ TAS2562_PB_CFG1, 0x20 },
{ TAS2562_TDM_CFG0, 0x09 },
{ TAS2562_TDM_CFG1, 0x02 },
+ { TAS2562_DVC_CFG1, 0x40 },
+ { TAS2562_DVC_CFG2, 0x40 },
+ { TAS2562_DVC_CFG3, 0x00 },
+ { TAS2562_DVC_CFG4, 0x00 },
};
static const struct regmap_config tas2562_regmap_config = {
diff --git a/sound/soc/codecs/tas2562.h b/sound/soc/codecs/tas2562.h
index 6f55ebcf19ea..28e75fc431d0 100644
--- a/sound/soc/codecs/tas2562.h
+++ b/sound/soc/codecs/tas2562.h
@@ -35,8 +35,10 @@
#define TAS2562_REV_ID TAS2562_REG(0, 0x7d)
/* Page 2 */
-#define TAS2562_DVC_CFG1 TAS2562_REG(2, 0x01)
-#define TAS2562_DVC_CFG2 TAS2562_REG(2, 0x02)
+#define TAS2562_DVC_CFG1 TAS2562_REG(2, 0x0c)
+#define TAS2562_DVC_CFG2 TAS2562_REG(2, 0x0d)
+#define TAS2562_DVC_CFG3 TAS2562_REG(2, 0x0e)
+#define TAS2562_DVC_CFG4 TAS2562_REG(2, 0x0f)
#define TAS2562_RESET BIT(0)
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] hw: move timer_new from init() into realize() to avoid memleaks
From: Philippe Mathieu-Daudé @ 2020-02-20 18:51 UTC (permalink / raw)
To: Peter Maydell, Pan Nengyuan
Cc: zhanghailiang, Alistair Francis, QEMU Developers,
mav2-rk.cave-ayland, qemu-arm, qemu-ppc, Euler Robot,
andrzej zaborowski, David Gibson
In-Reply-To: <CAFEAcA_AxCVaAgho3g2q=kCifSdhz9Qi72eoVAM9gRjb3-_Sog@mail.gmail.com>
On 2/20/20 6:56 PM, Peter Maydell wrote:
> On Mon, 17 Feb 2020 at 03:22, <pannengyuan@huawei.com> wrote:
>>
>> From: Pan Nengyuan <pannengyuan@huawei.com>
>>
>> There are some memleaks when we call 'device_list_properties'. This patch move timer_new from init into realize to fix it.
>> Meanwhile, do the null check in mos6522_reset() to avoid null deref if we move timer_new into realize().
>>
>> Reported-by: Euler Robot <euler.robot@huawei.com>
>> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com>
>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>
>
>> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
>> index 19e154b870..980eda7599 100644
>> --- a/hw/misc/mos6522.c
>> +++ b/hw/misc/mos6522.c
>> @@ -465,11 +465,15 @@ static void mos6522_reset(DeviceState *dev)
>> s->timers[0].frequency = s->frequency;
>> s->timers[0].latch = 0xffff;
>> set_counter(s, &s->timers[0], 0xffff);
>> - timer_del(s->timers[0].timer);
>> + if (s->timers[0].timer) {
>> + timer_del(s->timers[0].timer);
>> + }
>>
>> s->timers[1].frequency = s->frequency;
>> s->timers[1].latch = 0xffff;
>> - timer_del(s->timers[1].timer);
>> + if (s->timers[1].timer) {
>> + timer_del(s->timers[1].timer);
>> + }
>> }
>
> What code path calls a device 'reset' method on a device
> that has not yet been realized ? I wasn't expecting that
> to be valid...
This is not valid. What I understood while reviewing this patch is on
reset the timer is removed from the timers list. But this patch miss
setting timer = NULL in case the device is reset multiple times, here
can happen a NULL deref.
>
> thanks
> -- PMM
>
^ permalink raw reply
* [PATCH v2] ASoC: tas2562: Add support for digital volume control
From: Dan Murphy @ 2020-02-20 18:49 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai; +Cc: alsa-devel, linux-kernel, Dan Murphy
Add support for digital volume control. There is no dedicated register
for volume control but instead there are 4. The values of the registers
are determined with exponential floating point math.
So a table was created with register values for 2dB step increments
from -110dB to 0dB.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
v2 - Fix init values to lower volume CFG4 is the LSB and CFG1 is MSB
sound/soc/codecs/tas2562.c | 94 ++++++++++++++++++++++++++++++++++++++
sound/soc/codecs/tas2562.h | 6 ++-
2 files changed, 98 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/tas2562.c b/sound/soc/codecs/tas2562.c
index b2682c2360b6..92e4bf34b35c 100644
--- a/sound/soc/codecs/tas2562.c
+++ b/sound/soc/codecs/tas2562.c
@@ -26,6 +26,24 @@
#define TAS2562_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE |\
SNDRV_PCM_FORMAT_S32_LE)
+/* DVC equation involves floating point math
+ * round(10^(volume in dB/20)*2^30)
+ * so create a lookup table for 2dB step
+ */
+static const unsigned int float_vol_db_lookup[] = {
+0x00000d43, 0x000010b2, 0x00001505, 0x00001a67, 0x00002151,
+0x000029f1, 0x000034cd, 0x00004279, 0x000053af, 0x0000695b,
+0x0000695b, 0x0000a6fa, 0x0000d236, 0x000108a4, 0x00014d2a,
+0x0001a36e, 0x00021008, 0x000298c0, 0x000344df, 0x00041d8f,
+0x00052e5a, 0x000685c8, 0x00083621, 0x000a566d, 0x000d03a7,
+0x0010624d, 0x0014a050, 0x0019f786, 0x0020b0bc, 0x0029279d,
+0x0033cf8d, 0x004139d3, 0x00521d50, 0x00676044, 0x0082248a,
+0x00a3d70a, 0x00ce4328, 0x0103ab3d, 0x0146e75d, 0x019b8c27,
+0x02061b89, 0x028c423f, 0x03352529, 0x0409c2b0, 0x05156d68,
+0x080e9f96, 0x0a24b062, 0x0cc509ab, 0x10137987, 0x143d1362,
+0x197a967f, 0x2013739e, 0x28619ae9, 0x32d64617, 0x40000000
+};
+
struct tas2562_data {
struct snd_soc_component *component;
struct gpio_desc *sdz_gpio;
@@ -34,6 +52,7 @@ struct tas2562_data {
struct i2c_client *client;
int v_sense_slot;
int i_sense_slot;
+ int volume_lvl;
};
static int tas2562_set_bias_level(struct snd_soc_component *component,
@@ -334,6 +353,22 @@ static int tas2562_codec_probe(struct snd_soc_component *component)
if (ret < 0)
return ret;
+ /* Set the Digital volume to -110dB */
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG4, 0x43);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG3, 0x0d);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG2, 0x00);
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG1, 0x00);
+ if (ret)
+ return ret;
+
+ tas2562->volume_lvl = 0;
+
return 0;
}
@@ -414,6 +449,50 @@ static int tas2562_dac_event(struct snd_soc_dapm_widget *w,
return 0;
}
+static int tas2562_volume_control_get(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component = snd_soc_kcontrol_component(kcontrol);
+ struct tas2562_data *tas2562 = snd_soc_component_get_drvdata(component);
+
+ ucontrol->value.integer.value[0] = tas2562->volume_lvl;
+ return 0;
+}
+
+static int tas2562_volume_control_put(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_component *component = snd_soc_kcontrol_component(kcontrol);
+ struct tas2562_data *tas2562 = snd_soc_component_get_drvdata(component);
+ int ret;
+ u32 reg_val;
+
+ reg_val = float_vol_db_lookup[ucontrol->value.integer.value[0]/2];
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG4,
+ (reg_val & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG3,
+ ((reg_val >> 8) & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG2,
+ ((reg_val >> 16) & 0xff));
+ if (ret)
+ return ret;
+ ret = snd_soc_component_write(component, TAS2562_DVC_CFG1,
+ ((reg_val >> 24) & 0xff));
+ if (ret)
+ return ret;
+
+ tas2562->volume_lvl = ucontrol->value.integer.value[0];
+
+ return ret;
+}
+
+/* Digital Volume Control. From 0 dB to -110 dB in 1 dB steps */
+static const DECLARE_TLV_DB_SCALE(dvc_tlv, -11000, 100, 0);
+
static DECLARE_TLV_DB_SCALE(tas2562_dac_tlv, 850, 50, 0);
static const struct snd_kcontrol_new isense_switch =
@@ -427,6 +506,17 @@ static const struct snd_kcontrol_new vsense_switch =
static const struct snd_kcontrol_new tas2562_snd_controls[] = {
SOC_SINGLE_TLV("Amp Gain Volume", TAS2562_PB_CFG1, 0, 0x1c, 0,
tas2562_dac_tlv),
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .name = "Digital Volume Control",
+ .index = 0,
+ .tlv.p = dvc_tlv,
+ .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | SNDRV_CTL_ELEM_ACCESS_READWRITE,
+ .info = snd_soc_info_volsw,
+ .get = tas2562_volume_control_get,
+ .put = tas2562_volume_control_put,
+ .private_value = SOC_SINGLE_VALUE(TAS2562_DVC_CFG1, 0, 110, 0, 0) ,
+ },
};
static const struct snd_soc_dapm_widget tas2562_dapm_widgets[] = {
@@ -517,6 +607,10 @@ static const struct reg_default tas2562_reg_defaults[] = {
{ TAS2562_PB_CFG1, 0x20 },
{ TAS2562_TDM_CFG0, 0x09 },
{ TAS2562_TDM_CFG1, 0x02 },
+ { TAS2562_DVC_CFG1, 0x40 },
+ { TAS2562_DVC_CFG2, 0x40 },
+ { TAS2562_DVC_CFG3, 0x00 },
+ { TAS2562_DVC_CFG4, 0x00 },
};
static const struct regmap_config tas2562_regmap_config = {
diff --git a/sound/soc/codecs/tas2562.h b/sound/soc/codecs/tas2562.h
index 6f55ebcf19ea..28e75fc431d0 100644
--- a/sound/soc/codecs/tas2562.h
+++ b/sound/soc/codecs/tas2562.h
@@ -35,8 +35,10 @@
#define TAS2562_REV_ID TAS2562_REG(0, 0x7d)
/* Page 2 */
-#define TAS2562_DVC_CFG1 TAS2562_REG(2, 0x01)
-#define TAS2562_DVC_CFG2 TAS2562_REG(2, 0x02)
+#define TAS2562_DVC_CFG1 TAS2562_REG(2, 0x0c)
+#define TAS2562_DVC_CFG2 TAS2562_REG(2, 0x0d)
+#define TAS2562_DVC_CFG3 TAS2562_REG(2, 0x0e)
+#define TAS2562_DVC_CFG4 TAS2562_REG(2, 0x0f)
#define TAS2562_RESET BIT(0)
--
2.25.0
^ permalink raw reply related
* Re: BUG: git clean -d cannot remove files from read-only directories
From: Daniel Knittl-Frank @ 2020-02-20 18:46 UTC (permalink / raw)
To: Adam Milazzo; +Cc: git@vger.kernel.org
In-Reply-To: <BL0PR2101MB10898F2F84B06B1A6B23228380130@BL0PR2101MB1089.namprd21.prod.outlook.com>
Hi Adam,
On Thu, Feb 20, 2020 at 7:27 PM Adam Milazzo <Adam.Milazzo@microsoft.com> wrote:
>
> Repro steps:
> 1. git init
> 2. mkdir d
> 3. touch d/a
> 4. chmod -w d
> 5. git clean -fd
>
> Actual result:
> Git doesn't remove anything, saying "warning: failed to remove d/a".
>
>
> Expected result:
> Git should remove the subdirectory 'd' along with its contents. Note that git can remove a read-only file (touch b; chmod -w b; git clean -f) with no problem.
this is not a limitation of Git, but of how Linux Filesystems work.
When you delete a file, you do not modify the file, but you change the
directory which contains the file. In other words, if you have a
directory which is write protected (you do not have the write
permission), you cannot add, remove, or rename files. You may however
still modify the content existing files.
Your repro will yield the same result when executed without Git, i.e.
plain shell commands:
$ mkdir d ; touch d/a ; chmod a-w d
$ rm -rf d
rm: cannot remove 'd/a': Permission denied
If the write permission were removed before touching the file, this
would already fail:
$ mkdir d ; chmod a-w d
$ touch d/a
touch: cannot touch 'd/a': Permission denied
In summary: this is expected and I doubt Git can do much in such a
case. After all, the directory is marked as read-only, so why should
Git be able to write it? :)
> […]
>
> * It seems inconsistent for "git clean" to be able to remove read-only files but not files from read-only directories.
Again, deleting a file will modify its containing directory, not the
file itself. Making a file read-only does not protect it from being
renamed or deleted, that's what directory permissions are for.
- Daniel
--
typed with http://neo-layout.org
^ permalink raw reply
* Re: [PATCH v2] libtraceevent: add __print_hex_dump support
From: Steven Rostedt @ 2020-02-20 18:54 UTC (permalink / raw)
To: Piotr Maziarz
Cc: linux-kernel, acme, tstoyanov, andriy.shevchenko, cezary.rojewski,
gustaw.lewandowski
In-Reply-To: <1581337151-11231-1-git-send-email-piotrx.maziarz@linux.intel.com>
On Mon, 10 Feb 2020 13:19:11 +0100
Piotr Maziarz <piotrx.maziarz@linux.intel.com> wrote:
> This allows using parsing __print_hex_dump in user space tools. Print
> format is aligned with debugfs tracing interface.
>
> Signed-off-by: Piotr Maziarz <piotrx.maziarz@linux.intel.com>
> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
> ---
> v2:
> Fix checkpatch warning
> Use is_power_of_2() function
>
>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-- Steve
^ permalink raw reply
* Re: [meta-oe][PATCH 2/2] s3c24xx-gpio, s3c64xx-gpio, sjf2410-linux-native, usbpath, wmiconfig: remove old recipes
From: Martin Jansa @ 2020-02-20 18:54 UTC (permalink / raw)
To: Khem Raj; +Cc: openembedded-devel
In-Reply-To: <af60d8a0-618c-7b85-034a-c0118d1cec0b@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]
On Thu, Feb 20, 2020 at 10:19:24AM -0800, Khem Raj wrote:
>
>
> On 2/20/20 9:52 AM, Martin Jansa wrote:
> > * I don't expect anyone nowadays actually using these recipes which I've
> > imported from meta-smartphone in 2011.
> >
> > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> > ---
> > .../packagegroups/packagegroup-meta-oe.bb | 8 +-
> > .../0001-ppt.c-Do-not-include-sys-io.h.patch | 28 -
> > .../samsung-soc-utils/s3c24xx-gpio_git.bb | 21 -
> > .../samsung-soc-utils/s3c64xx-gpio_git.bb | 21 -
> > .../sjf2410-linux-native_git.bb | 39 --
> > .../usbpath/usbpath/configure.patch | 11 -
> > .../recipes-support/usbpath/usbpath_git.bb | 21 -
> > ...0001-makefile-Pass-CFLAGS-to-compile.patch | 26 -
> > ...02-fix-err-API-to-have-format-string.patch | 656 ------------------
> > .../wmiconfig/wmiconfig_git.bb | 24 -
> > 10 files changed, 4 insertions(+), 851 deletions(-)
> > delete mode 100644 meta-oe/recipes-support/samsung-soc-utils/files/0001-ppt.c-Do-not-include-sys-io.h.patch
> > delete mode 100644 meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_git.bb
> > delete mode 100644 meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_git.bb
> > delete mode 100644 meta-oe/recipes-support/samsung-soc-utils/sjf2410-linux-native_git.bb
> > delete mode 100644 meta-oe/recipes-support/usbpath/usbpath/configure.patch
> > delete mode 100644 meta-oe/recipes-support/usbpath/usbpath_git.bb
> > delete mode 100644 meta-oe/recipes-support/wmiconfig/wmiconfig/0001-makefile-Pass-CFLAGS-to-compile.patch
> > delete mode 100644 meta-oe/recipes-support/wmiconfig/wmiconfig/0002-fix-err-API-to-have-format-string.patch
> > delete mode 100644 meta-oe/recipes-support/wmiconfig/wmiconfig_git.bb
> >
>
> I had to manually apply is on master-next, please check master-next if all
> is fine or else send a rebase on top of master-next
Looks the same as what I have locally, thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/6] NFS: Add READ_PLUS data segment support
From: Chuck Lever @ 2020-02-20 18:54 UTC (permalink / raw)
To: Anna Schumaker; +Cc: Trond.Myklebust, Linux NFS Mailing List
In-Reply-To: <2c46295c6a6e748947af226dc470f7e35a2c6e82.camel@gmail.com>
> On Feb 20, 2020, at 1:35 PM, Anna Schumaker <schumaker.anna@gmail.com> wrote:
>
> On Thu, 2020-02-20 at 13:30 -0500, Chuck Lever wrote:
>>> On Feb 20, 2020, at 1:28 PM, Anna Schumaker <schumaker.anna@gmail.com>
>>> wrote:
>>>
>>> On Thu, 2020-02-20 at 09:55 -0500, Chuck Lever wrote:
>>>
>>>> The down-side here is that would make NFSv4.2 on RDMA
>>>> unable to recognize holes in files the same way as it
>>>> does on TCP, and that's a pretty significant variation
>>>> in behavior. Does "noreadplus" even deal with that?
>>>
>>> Setting "noreadplus" just causes the client to use the READ operation
>>> instead,
>>> so there should be no difference between v4.1 and v4.2 if the option is set.
>>
>> My concern is the difference between NFSv4.2 with noreadplus
>> and NFSv4.2 with readplus. The former is not able to detect
>> holes in files on the server, but the latter is.
>
> The client could still use lseek to detect holes. The client throws away the
> hole information after xdr decoding, and zeroes out the corresponding pages for
> the page cache.
Then maybe that's an optimization for another day. The READ_PLUS
reply can have hole information. The client could save itself some
SEEK_HOLE operations if it cached that hole information somehow.
But if "readplus" and "noreadplus" result in exactly the same hole
retention behavior on our client, I guess there's no harm in using
"noreadplus" instead, except for possible performance regression.
An alternative to making "noreadplus" the default would be to
temporarily add "noreadplus" semantics to the "proto=rdma" mount
option, as a separate patch; maybe after some performance results
show that it is necessary. That would keep the mount interface a
little less complicated.
--
Chuck Lever
^ permalink raw reply
* [Printing-architecture] Fwd: [GSoC Mentors] GSoC 2020 Mentoring Organizations have been announced
From: Ira McDonald @ 2020-02-20 18:53 UTC (permalink / raw)
To: printing-architecture@lists.linux-foundation.org, ipp@pwg.org,
Ira McDonald
In-Reply-To: <4c5c67df-d845-4b43-a8d0-49fe76c909b1@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]
Hi,
Linux Foundation was just accepted as a GSoC 2020 mentor organization.
So we can move forward with plans for OpenPrinting collaboration with PWG
on IPP-related projects (several are planned).
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
(to 30 April 2020) 203 W Oak St Ellettsville, IN 47429 812-876-9970
---------- Forwarded message ---------
From: 'sttaylor' via Google Summer of Code Mentors List <
google-summer-of-code-mentors-list@googlegroups.com>
Date: Thu, Feb 20, 2020 at 1:48 PM
Subject: [GSoC Mentors] GSoC 2020 Mentoring Organizations have been
announced
To: Google Summer of Code Mentors List <
google-summer-of-code-mentors-list@googlegroups.com>
We have accepted 200 open source organizations
<https://summerofcode.withgoogle.com/organizations/> for the 2020 Google
Summer of Code program <http://g.co/gsoc>.
Now is the time for students to start reaching out to organizations that
interest them and to learn more about their communities and the work they
do.
Students will be able to register for GSoC when the application period
opens on March 16 - March 31.
--
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Mentors List" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-mentors-list+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/4c5c67df-d845-4b43-a8d0-49fe76c909b1%40googlegroups.com
<https://groups.google.com/d/msgid/google-summer-of-code-mentors-list/4c5c67df-d845-4b43-a8d0-49fe76c909b1%40googlegroups.com?utm_medium=email&utm_source=footer>
.
[-- Attachment #2: Type: text/html, Size: 4057 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] of: unittest: add overlay gpio test to catch gpio hog problem
From: Frank Rowand @ 2020-02-20 18:53 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, pantelis.antoniou, devicetree, linux-kernel,
Alan Tull
In-Reply-To: <ff65f982-f71e-5bef-1811-fdb94fd7da2f@gmail.com>
On 2/19/20 5:37 PM, Frank Rowand wrote:
> On 2/19/20 3:56 PM, Rob Herring wrote:
>> On Tue, Jan 28, 2020 at 11:46:04PM -0600, frowand.list@gmail.com wrote:
>>> From: Frank Rowand <frank.rowand@sony.com>
>>>
>>> Geert reports that gpio hog nodes are not properly processed when
>>> the gpio hog node is added via an overlay reply and provides an
>>> RFC patch to fix the problem [1].
>>>
>>> Add a unittest that shows the problem. Unittest will report "1 failed"
>>> test before applying Geert's RFC patch and "0 failed" after applying
>>> Geert's RFC patch.
>>
>> What's the status of that? I don't want to leave the tests failing at
>> least outside of a kernel release.
>
> I agree. I would like to see my patches applied, showing the test fail,
> immediately followed by Geert's fix. So my series should not go in
> until Geert's patch is ready.
Geert has sent a v2 patch series.
I have sent a v2 of this patch, tested with v2 of Geert's patch series.
-Frank
>
>>
>>>
>>> [1] https://lore.kernel.org/linux-devicetree/20191230133852.5890-1-geert+renesas@glider.be/
>>>
>>> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
>>> ---
>>>
>>> There are checkpatch warnings.
>>> - New files are in a directory already covered by MAINTAINERS
>>> - The undocumented compatibles are restricted to use by unittest
>>> and should not be documented under Documentation
>>> - The printk() KERN_<LEVEL> warnings are false positives. The level
>>> is supplied by a define parameter instead of a hard coded constant
>>> - The lines over 80 characters are consistent with unittest.c style
>>>
>>> This unittest was also valuable in that it allowed me to explore
>>> possible issues related to the proposed solution to the gpio hog
>>> problem.
>>>
>>> changes since RFC:
>>> - fixed node names in overlays
>>> - removed unused fields from struct unittest_gpio_dev
>>> - of_unittest_overlay_gpio() cleaned up comments
>>> - of_unittest_overlay_gpio() moved saving global values into
>>> probe_pass_count and chip_request_count more tightly around
>>> test code expected to trigger changes in the global values
>>>
>>> drivers/of/unittest-data/Makefile | 8 +-
>>> drivers/of/unittest-data/overlay_gpio_01.dts | 23 +++
>>> drivers/of/unittest-data/overlay_gpio_02a.dts | 16 ++
>>> drivers/of/unittest-data/overlay_gpio_02b.dts | 16 ++
>>> drivers/of/unittest-data/overlay_gpio_03.dts | 23 +++
>>> drivers/of/unittest-data/overlay_gpio_04a.dts | 16 ++
>>> drivers/of/unittest-data/overlay_gpio_04b.dts | 16 ++
>>> drivers/of/unittest.c | 255 ++++++++++++++++++++++++++
>>> 8 files changed, 372 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_01.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_02a.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_02b.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_03.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_04a.dts
>>> create mode 100644 drivers/of/unittest-data/overlay_gpio_04b.dts
>>>
>>> diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
>>> index 9b6807065827..009f4045c8e4 100644
>>> --- a/drivers/of/unittest-data/Makefile
>>> +++ b/drivers/of/unittest-data/Makefile
>>> @@ -21,7 +21,13 @@ obj-$(CONFIG_OF_OVERLAY) += overlay.dtb.o \
>>> overlay_bad_add_dup_prop.dtb.o \
>>> overlay_bad_phandle.dtb.o \
>>> overlay_bad_symbol.dtb.o \
>>> - overlay_base.dtb.o
>>> + overlay_base.dtb.o \
>>> + overlay_gpio_01.dtb.o \
>>> + overlay_gpio_02a.dtb.o \
>>> + overlay_gpio_02b.dtb.o \
>>> + overlay_gpio_03.dtb.o \
>>> + overlay_gpio_04a.dtb.o \
>>> + overlay_gpio_04b.dtb.o
>>>
>>> # enable creation of __symbols__ node
>>> DTC_FLAGS_overlay += -@
>>> diff --git a/drivers/of/unittest-data/overlay_gpio_01.dts b/drivers/of/unittest-data/overlay_gpio_01.dts
>>> new file mode 100644
>>> index 000000000000..f039e8bce3b6
>>> --- /dev/null
>>> +++ b/drivers/of/unittest-data/overlay_gpio_01.dts
>>> @@ -0,0 +1,23 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +&unittest_test_bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + gpio_01 {
>>
>> Missing unit address:
>>
>> gpio@0
>
> But my changelog claimed that I fixed that, isn't that
> good enough? :-)
>
> /me pulls big brown paper bag over head.
>
> And the same for all the issues you point out below, for the
> second patch version in a row.
>
> I'll re-spin on 5.6-rc1 and truly include the fixes.
>
> -Frank
>
>
>>
>>
>>> + compatible = "unittest-gpio";
>>> + reg = <0>;
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + ngpios = <2>;
>>> + gpio-line-names = "line-A", "line-B";
>>> +
>>> + line_b {
>>
>> Don't use '_'.
>>
>> line-b
>>
>>> + gpio-hog;
>>> + gpios = <2 0>;
>>> + input;
>>> + line-name = "line-B-input";
>>> + };
>>> + };
>>> +};
>>> diff --git a/drivers/of/unittest-data/overlay_gpio_02a.dts b/drivers/of/unittest-data/overlay_gpio_02a.dts
>>> new file mode 100644
>>> index 000000000000..cdafab604793
>>> --- /dev/null
>>> +++ b/drivers/of/unittest-data/overlay_gpio_02a.dts
>>> @@ -0,0 +1,16 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +&unittest_test_bus {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + gpio_02 {
>>
>> gpio@1
>>
>> ...and a few more.
>>
>>> + compatible = "unittest-gpio";
>>> + reg = <1>;
>>> + gpio-controller;
>>> + #gpio-cells = <2>;
>>> + ngpios = <2>;
>>> + gpio-line-names = "line-A", "line-B";
>>> + };
>>> +};
>>
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.