Re: [LKP] [mac80211] c752cac9db: hwsim.ap_vlan_iface_cleanup_multibss_per_sta_vif.fail

[kernel test robot]

On Thu, Mar 07, 2019 at 07:49:11AM +, Tony Chuang wrote:
> 
> 
> > -Original Message-
> > From: kernel test robot [mailto:rong.a.c...@intel.com]
> > Sent: Thursday, March 07, 2019 3:05 PM
> > To: Tony Chuang
> > Cc: Johannes Berg; Larry Finger; LKML; Linus Torvalds; l...@01.org
> > Subject: [LKP] [mac80211] c752cac9db:
> > hwsim.ap_vlan_iface_cleanup_multibss_per_sta_vif.fail
> > 
> > FYI, we noticed the following commit (built with gcc-8):
> > 
> > commit: c752cac9db1b0c469db7ba9d17af4ba708984db5 ("mac80211: fix
> > GFP_KERNEL under tasklet context")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > 
> > in testcase: hwsim
> > with following parameters:
> > 
> > group: hwsim-02
> > 
> > 
> > 
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2
> > -m 4G
> > 
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> > 
> 
> <...>
> 
> > 
> > 2019-03-06 14:51:15 ./run-tests.py ap_vlan_iface_cleanup_multibss
> > DEV: wlan0: 02:00:00:00:00:00
> > DEV: wlan1: 02:00:00:00:01:00
> > DEV: wlan2: 02:00:00:00:02:00
> > APDEV: wlan3
> > APDEV: wlan4
> > START ap_vlan_iface_cleanup_multibss 1/1
> > Test: AP VLAN operation in multi-BSS multi-VLAN case
> > RTNETLINK answers: File exists
> > Starting AP wlan4
> > Starting interface wlan3
> > Connect STA wlan0 to AP
> > Connect STA wlan1 to AP
> > wlan0 -> VLAN 2
> > test wlan1 == VLAN 1
> > wlan1 -> VLAN 2
> > test wlan0 == VLAN 2
> > PASS ap_vlan_iface_cleanup_multibss 3.037115 2019-03-06 14:51:19.362536
> > passed all 1 test case(s)
> > 2019-03-06 14:51:19 ./run-tests.py
> > ap_vlan_iface_cleanup_multibss_per_sta_vif
> > DEV: wlan0: 02:00:00:00:00:00
> > DEV: wlan1: 02:00:00:00:01:00
> > DEV: wlan2: 02:00:00:00:02:00
> > APDEV: wlan3
> > APDEV: wlan4
> > START ap_vlan_iface_cleanup_multibss_per_sta_vif 1/1
> > Test: AP VLAN operation in multi-BSS multi-VLAN case with per-sta-vif set
> > Starting AP wlan4
> > Starting interface wlan3
> > Connect STA wlan0 to AP
> > Connect STA wlan1 to AP
> > dev1->dev2 unicast data delivery failed
> > Traceback (most recent call last):
> >   File "./run-tests.py", line 466, in main
> > t(dev, apdev)
> >   File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 505, in
> > test_ap_vlan_iface_cleanup_multibss_per_sta_vif
> > 'multi-bss-iface-per_sta_vif.conf')
> >   File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 413, in
> > ap_vlan_iface_cleanup_multibss
> > hwsim_utils.test_connectivity_iface(dev[1], hapd1, "brvlan1")
> >   File "/lkp/benchmarks/hwsim/tests/hwsim/hwsim_utils.py", line 176, in
> > test_connectivity_iface
> > max_tries=max_tries, timeout=timeout)
> >   File "/lkp/benchmarks/hwsim/tests/hwsim/hwsim_utils.py", line 169, in
> > test_connectivity
> > raise Exception(last_err)
> > Exception: dev1->dev2 unicast data delivery failed
> > FAIL ap_vlan_iface_cleanup_multibss_per_sta_vif 6.917146 2019-03-06
> > 14:51:26.784664
> > passed 0 test case(s)
> > skipped 0 test case(s)
> > failed tests: ap_vlan_iface_cleanup_multibss_per_sta_vif
> 
> <...>
> 
> > 
> > 
> > To reproduce:
> > 
> > # build kernel
> > cd linux
> > cp config-4.19.0-12453-gc752cac .config
> > make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 olddefconfig
> > make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 prepare
> > make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 modules_prepare
> > make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 SHELL=/bin/bash
> > make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 bzImage
> > 
> > 
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp qemu -k  job-script # job-script is attached in 
> > this
> > email
> > 
> > 
> > 
> > Thanks,
> > Rong Chen
> 
> 
> It looks really strange that this patch failed the test.
> And I checked the dmesg, the log shows me that
> 
> PASS ap_vlan_iface_cleanup_multibss_per_sta_vif
> 
> At line 24000.

Hi,

This doesn't happen every time. Here is a bad result:

2019-03-06 14:51:19 ./run-tests.py 
ap_vlan_iface_cleanup_multibss_per_sta_vif 
DEV: wlan0: 02:00:00:00:00:00
DEV: wlan1: 02:00:00:00:01:00
DEV: wlan2: 02:00:00:00:02:00
APDEV: wlan3
APDEV: wlan4
START ap_vlan_iface_cleanup_multibss_per_sta_vif 1/1
Test: AP VLAN operation in multi-BSS multi-VLAN case with per-sta-vif set
Starting AP wlan4
Starting interface wlan3
Connect STA wlan0 to AP
Connect STA wlan1 to AP
dev1->dev2 unicast data delivery failed
Traceback (most recent call last):
  File "./run-tests.py", line 466, in main
t(dev, apdev)
  File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 505, in 
test_ap_vlan_iface_cleanup_multibss_per_sta_vif
'multi-bss-iface-per_sta_vif.conf')
  File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 413, in 
ap_vlan_iface_cleanup_multibss
hwsim_utils.test_connectivity_iface(dev[1], hapd1, "brvlan1")
  File "/lkp/benchmarks/hwsim/tests/hwsim/hwsim_utils.py", line 176, in 

Re: KASAN: use-after-free Read in get_mem_cgroup_from_mm

[zhong jiang]

On 2019/3/7 2:29, Andrea Arcangeli wrote:
> Hello Zhong,
>
> On Wed, Mar 06, 2019 at 09:07:00PM +0800, zhong jiang wrote:
>> The patch use call_rcu to delay free the task_struct, but It is possible to 
>> free the task_struct
>> ahead of get_mem_cgroup_from_mm. is it right?
> Yes it is possible to free before get_mem_cgroup_from_mm, but if it's
> freed before get_mem_cgroup_from_mm rcu_read_lock,
> rcu_dereference(mm->owner) will return NULL in such case and there
> will be no problem.
Yes
> The simple fix also clears the mm->owner of the failed-fork-mm before
> doing the call_rcu. The call_rcu delays the freeing after no other CPU
> runs in between rcu_read_lock/unlock anymore. That guarantees that
> those critical section will see mm->owner == NULL if the freeing of
> the task strut already happened.
We has set the mm->owner to NULL when child process fails to fork ahead of 
freeing
the task struct.

Have those critical section  chance to see the mm->owner, which is not NULL.

I has tested the patch.  Not Oops and panic appear  so far.

Thanks,
zhong jiang
> The solution Mike suggested for this and that we were wondering as
> ideal in the past for the signal issue too, is to move the uffd
> delivery at a point where fork is guaranteed to succeed. We should
> probably try that too to see how it looks like and if it can be done
> in a not intrusive way, but the simple fix that uses RCU should work
> too.
>
> Rolling back in case of errors inside fork itself isn't easily doable:
> the moment we push the uffd ctx to the other side of the uffd pipe
> there's no coming back as that information can reach the userland of
> the uffd monitor/reader thread immediately after. The rolling back is
> really the other thread failing at mmget_not_zero eventually. It's the
> userland that has to rollback in such case when it gets a -ESRCH
> retval.
>
> Note that this fork feature is only ever needed in the non-cooperative
> case, these things never need to happen when userfaultfd is used by an
> app (or a lib) that is aware that it is using userfaultfd.
>
> Thanks,
> Andrea
>
> .
>

[PATCH] lockdep: avoid a clang warning

[Arnd Bergmann]

Clang warns about a tentative array definition without a length:

kernel/locking/lockdep.c:845:12: error: tentative array definition assumed to 
have one element [-Werror]

There is no real reason to do this here, so just set the same length as
in the real definition later in the same file.  It has to be hidden in
an #ifdef or annotated __maybe_unused though, to avoid the unused-variable
warning if CONFIG_PROVE_LOCKING is disabled.

Signed-off-by: Arnd Bergmann 
---
 kernel/locking/lockdep.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 21cb81fe6359..35a144dfddf5 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -842,7 +842,9 @@ static bool class_lock_list_valid(struct lock_class *c, 
struct list_head *h)
return true;
 }
 
-static u16 chain_hlocks[];
+#ifdef CONFIG_PROVE_LOCKING
+static u16 chain_hlocks[MAX_LOCKDEP_CHAIN_HLOCKS];
+#endif
 
 static bool check_lock_chain_key(struct lock_chain *chain)
 {
-- 
2.20.0

Re: [Y2038] Question regarding support of old time interfaces beyond y2038

[Lukasz Majewski]

Hi Zack,

> On Tue, Mar 5, 2019 at 10:24 AM Lukasz Majewski  wrote:
> > From other discussion [4] - regarding the following system calls:
> >  time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> > alarm, getitimer, setitimer, select, utime, utimes, futimesat, and
> >  {old,new}{l,f,}stat{,64}.
> >
> > "These all pass 32-bit time_t arguments on 32-bit
> >  architectures and are replaced by other interfaces (e.g. posix
> >  timers and clocks, statx). C libraries implementing 64-bit time_t
> > in 32-bit architectures have to implement the handles by wrapping
> >  around the newer interfaces."  
> 
> 1) We should be clear that most of these will continue to be supported
> as C library interfaces even if they are not system calls.  Some of
> them are obsolete enough and/or rarely used enough that we might not
> bother (the older ways to set the system clock, for instance).

The question here is about the decision if even the old time APIs shall
be supported on 32 bit systems which are going to be Y2038 proof (like
the 'stime').

> 
> 2) I know of one case where the new interfaces don't cover all of the
> functionality of the old ones: timers started by setitimer continue to
> run after an execve, timers started by timer_create don't.  This means
> setitimer(ITIMER_VIRTUAL) can be used to impose a CPU time limit on a
> program you didn't write, and timer_create can't.  If new kernels are
> not going to have setitimer as a primitive, we need some other way of
> getting the same effect.
> 
> zw




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpfXe8Un4Owt.pgp
Description: OpenPGP digital signature

[PATCH] page flags: prioritize kasan bits over last-cpuid

[Arnd Bergmann]

ARM64 randdconfig builds regularly run into a build error, especially
when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP:

 #error "KASAN: not enough bits in page flags for tag"

The last-cpuid bits are already contitional on the available space,
so the result of the calculation is a bit random on whether they
were already left out or not.

Adding the kasan tag bits before last-cpuid makes it much more likely
to end up with a successful build here, and should be reliable for
randconfig at least, as long as that does not randomize NR_CPUS
or NODES_SHIFT but uses the defaults.

Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via 
pagealloc")
Signed-off-by: Arnd Bergmann 
---
 include/linux/page-flags-layout.h | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/linux/page-flags-layout.h 
b/include/linux/page-flags-layout.h
index 1dda31825ec4..9bc0751e68b2 100644
--- a/include/linux/page-flags-layout.h
+++ b/include/linux/page-flags-layout.h
@@ -76,21 +76,23 @@
 #define LAST_CPUPID_SHIFT 0
 #endif
 
-#if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT <= BITS_PER_LONG 
- NR_PAGEFLAGS
+#ifdef CONFIG_KASAN_SW_TAGS
+#define KASAN_TAG_WIDTH 8
+#else
+#define KASAN_TAG_WIDTH 0
+#endif
+
+#if SECTIONS_WIDTH+ZONES_WIDTH+NODES_SHIFT+LAST_CPUPID_SHIFT+KASAN_TAG_WIDTH \
+   <= BITS_PER_LONG - NR_PAGEFLAGS
 #define LAST_CPUPID_WIDTH LAST_CPUPID_SHIFT
 #else
 #define LAST_CPUPID_WIDTH 0
 #endif
 
-#ifdef CONFIG_KASAN_SW_TAGS
-#define KASAN_TAG_WIDTH 8
 #if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH+LAST_CPUPID_WIDTH+KASAN_TAG_WIDTH \
> BITS_PER_LONG - NR_PAGEFLAGS
 #error "KASAN: not enough bits in page flags for tag"
 #endif
-#else
-#define KASAN_TAG_WIDTH 0
-#endif
 
 /*
  * We are going to use the flags for the page to node mapping if its in
-- 
2.20.0

Re: [PATCH] sched: fair: fix missed CONFIG_SCHEDSTATS

[Yafang Shao]

On Wed, Mar 6, 2019 at 8:53 PM Yafang Shao  wrote:
>
> On Wed, Mar 6, 2019 at 8:38 PM Peter Zijlstra  wrote:
> >
> > On Wed, Mar 06, 2019 at 07:49:36PM +0800, Yafang Shao wrote:
> >
> >
> > $ grep SCHEDSTAT defconfig-build/.config
> > # CONFIG_SCHEDSTATS is not set
> > $ obbjdump -dr defconfig-build/kernel/sched/fair.o | awk '/>:$/ { F=$2 } 
> > /sched_stat/ { print F " " $0 }'
> > :  24cd: R_X86_64_32S  
> > __tracepoint_sched_stat_runtime+0x28
> > :  24d9: R_X86_64_PC32 
> > __tracepoint_sched_stat_runtime+0x24
> > $ patch -p1 < foo
> > patching file kernel/sched/fair.c
> > $ make O=defconfig-build kernel/sched/
> > make[1]: Entering directory '/usr/src/linux-2.6/defconfig-build'
> > Using .. as source for kernel
> > GEN Makefile
> > CALL../scripts/checksyscalls.sh
> > CALL../scripts/atomic/check-atomics.sh
> > DESCEND  objtool
> > CC  kernel/sched/fair.o
> > AR  kernel/sched/built-in.a
> > make[1]: Leaving directory '/usr/src/linux-2.6/defconfig-build'
> > $ objdump -dr defconfig-build/kernel/sched/fair.o | awk '/>:$/ { F=$2 } 
> > /sched_stat/ { print F " " $0 }'
> > $ cat foo
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 8213ff6e365d..6e5ceec3b662 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -839,7 +839,8 @@ static void update_curr(struct cfs_rq *cfs_rq)
> > if (entity_is_task(curr)) {
> > struct task_struct *curtask = task_of(curr);
> >
> > -   trace_sched_stat_runtime(curtask, delta_exec, 
> > curr->vruntime);
> > +   if (schedstat_enabled())
> > +   trace_sched_stat_runtime(curtask, delta_exec, 
> > curr->vruntime);
> > cgroup_account_cputime(curtask, delta_exec);
> > account_group_exec_runtime(curtask, delta_exec);
> > }
> >
> >
> > _1_ line, where you wanted to add _6_ ugly #ifdefs
>
> I get your point now.
>
> Yes, these codes can be removed from the callsites in kernel/sched/fair.c,
> but the definitions of these tracepoints are still there,
> and then they will be exposed in /sys/kernel/debug/tracing/events/sched/.
>
> You can try objdump the vmlinux.
> $ objdump -dr kernel/sched/fair.o | awk '/>:$/ { F=$2 } /sched_stat/ {
> print F " " $0 }'// nothing
>
> $ objdump -dr vmlinux  | awk '/>:$/ { F=$2 } /sched_stat/ { print F " " $0 }'
> : 810b3c30
> :  // it is still defined
>
>
> My guess is they will be used by perf or bpf,
> so they won't be optimized out by the compiler.
>

Hi Peter,

If you do not like sprinkle #ifdef, we can use something like bellow
to resovle this issue.
I don't like bellow code really, but it can avoid exposing these
tracepoints to the userspace.

What about your opinon ?


diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 9a4bdfa..a0291f2 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -336,6 +336,7 @@ static inline long __trace_sched_switch_state(bool
preempt, struct task_struct *
  __entry->pid, __entry->old_pid)
 );

+#ifdef CONFIG_SCHEDSTATS
 /*
  * XXX the below sched_stat tracepoints only apply to SCHED_OTHER/BATCH/IDLE
  * adding sched_stat support to SCHED_FIFO/RR would be welcome.
@@ -394,6 +395,14 @@ static inline long
__trace_sched_switch_state(bool preempt, struct task_struct *
 DEFINE_EVENT(sched_stat_template, sched_stat_blocked,
 TP_PROTO(struct task_struct *tsk, u64 delay),
 TP_ARGS(tsk, delay));
+#else
+
+#define trace_sched_stat_wait(...) do {} while (0)
+#define trace_sched_stat_sleep(...) do {} while (0)
+#define trace_sched_stat_iowait(...) do {} while (0)
+#define trace_sched_stat_blocked(...) do {} while (0)
+
+#endif

 /*
  * Tracepoint for accounting runtime (time the task is executing


Thanks
Yafang

RE: [LKP] [mac80211] c752cac9db: hwsim.ap_vlan_iface_cleanup_multibss_per_sta_vif.fail

[Tony Chuang]

> -Original Message-
> From: kernel test robot [mailto:rong.a.c...@intel.com]
> Sent: Thursday, March 07, 2019 3:05 PM
> To: Tony Chuang
> Cc: Johannes Berg; Larry Finger; LKML; Linus Torvalds; l...@01.org
> Subject: [LKP] [mac80211] c752cac9db:
> hwsim.ap_vlan_iface_cleanup_multibss_per_sta_vif.fail
> 
> FYI, we noticed the following commit (built with gcc-8):
> 
> commit: c752cac9db1b0c469db7ba9d17af4ba708984db5 ("mac80211: fix
> GFP_KERNEL under tasklet context")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: hwsim
> with following parameters:
> 
>   group: hwsim-02
> 
> 
> 
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2
> -m 4G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
> 

<...>

> 
> 2019-03-06 14:51:15   ./run-tests.py ap_vlan_iface_cleanup_multibss
> DEV: wlan0: 02:00:00:00:00:00
> DEV: wlan1: 02:00:00:00:01:00
> DEV: wlan2: 02:00:00:00:02:00
> APDEV: wlan3
> APDEV: wlan4
> START ap_vlan_iface_cleanup_multibss 1/1
> Test: AP VLAN operation in multi-BSS multi-VLAN case
> RTNETLINK answers: File exists
> Starting AP wlan4
> Starting interface wlan3
> Connect STA wlan0 to AP
> Connect STA wlan1 to AP
> wlan0 -> VLAN 2
> test wlan1 == VLAN 1
> wlan1 -> VLAN 2
> test wlan0 == VLAN 2
> PASS ap_vlan_iface_cleanup_multibss 3.037115 2019-03-06 14:51:19.362536
> passed all 1 test case(s)
> 2019-03-06 14:51:19   ./run-tests.py
> ap_vlan_iface_cleanup_multibss_per_sta_vif
> DEV: wlan0: 02:00:00:00:00:00
> DEV: wlan1: 02:00:00:00:01:00
> DEV: wlan2: 02:00:00:00:02:00
> APDEV: wlan3
> APDEV: wlan4
> START ap_vlan_iface_cleanup_multibss_per_sta_vif 1/1
> Test: AP VLAN operation in multi-BSS multi-VLAN case with per-sta-vif set
> Starting AP wlan4
> Starting interface wlan3
> Connect STA wlan0 to AP
> Connect STA wlan1 to AP
> dev1->dev2 unicast data delivery failed
> Traceback (most recent call last):
>   File "./run-tests.py", line 466, in main
> t(dev, apdev)
>   File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 505, in
> test_ap_vlan_iface_cleanup_multibss_per_sta_vif
> 'multi-bss-iface-per_sta_vif.conf')
>   File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_vlan.py", line 413, in
> ap_vlan_iface_cleanup_multibss
> hwsim_utils.test_connectivity_iface(dev[1], hapd1, "brvlan1")
>   File "/lkp/benchmarks/hwsim/tests/hwsim/hwsim_utils.py", line 176, in
> test_connectivity_iface
> max_tries=max_tries, timeout=timeout)
>   File "/lkp/benchmarks/hwsim/tests/hwsim/hwsim_utils.py", line 169, in
> test_connectivity
> raise Exception(last_err)
> Exception: dev1->dev2 unicast data delivery failed
> FAIL ap_vlan_iface_cleanup_multibss_per_sta_vif 6.917146 2019-03-06
> 14:51:26.784664
> passed 0 test case(s)
> skipped 0 test case(s)
> failed tests: ap_vlan_iface_cleanup_multibss_per_sta_vif

<...>

> 
> 
> To reproduce:
> 
> # build kernel
>   cd linux
>   cp config-4.19.0-12453-gc752cac .config
>   make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 olddefconfig
>   make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 prepare
>   make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 modules_prepare
>   make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 SHELL=/bin/bash
>   make HOSTCC=gcc-8 CC=gcc-8 ARCH=x86_64 bzImage
> 
> 
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k  job-script # job-script is attached in this
> email
> 
> 
> 
> Thanks,
> Rong Chen


It looks really strange that this patch failed the test.
And I checked the dmesg, the log shows me that

PASS ap_vlan_iface_cleanup_multibss_per_sta_vif

At line 24000.

So I think I need to reproduce this to confirm it.
Or anyone has any idea please let me know.
Thanks

Yan-Hsuan

Re: [Y2038] Question regarding support of old time interfaces beyond y2038

[Lukasz Majewski]

Hi Arnd,

> On Tue, Mar 5, 2019 at 4:24 PM Lukasz Majewski  wrote:
> >
> > Dear Arnd,
> >
> > In your "playground" repository [1] (branch: y2038), the time
> > functions (stime, settimeofday, etc) are not converted in Linux to
> > be Y2038 aware (as for example clock_settime{64}() is).  
> 
> Correct. FWIW, this is now merged into the mainline kernel.
> 

The arch/arm/tools/syscall.tbl
linux-next 20190306
SHA1: cf08baa29613dd899954089e7cc7dba1d478b365

Has now:

403 common  clock_gettime64 sys_clock_gettime
404 common  clock_settime64 sys_clock_settime
405 common  clock_adjtime64 sys_clock_adjtime
406 common  clock_getres_time64 sys_clock_getres
407 common  clock_nanosleep_time64  sys_clock_nanosleep
408 common  timer_gettime64 sys_timer_gettime
409 common  timer_settime64 sys_timer_settime
410 common  timerfd_gettime64   sys_timerfd_gettime
411 common  timerfd_settime64   sys_timerfd_settime
412 common  utimensat_time64sys_utimensat
413 common  pselect6_time64 sys_pselect6
414 common  ppoll_time64sys_ppoll
416 common  io_pgetevents_time64sys_io_pgetevents
417 common  recvmmsg_time64 sys_recvmmsg
418 common  mq_timedsend_time64 sys_mq_timedsend
419 common  mq_timedreceive_time64  sys_mq_timedreceive
420 common  semtimedop_time64   sys_semtimedop
421 common  rt_sigtimedwait_time64  sys_rt_sigtimedwait
422 common  futex_time64sys_futex
423 common  sched_rr_get_interval_time64
sys_sched_rr_get_interval

> > I've also searched on the Internet and I've found some old
> > discussions regarding them:
> >
> > SHA1:  d33c577cccd0b3e5bb2425f85037f26714a59363 [2]
> > From commit message:
> >
> > "The time, stime, utime, utimes, and futimesat system calls are only
> > used on older architectures, and we do not provide y2038 safe
> > variants of them, as they are replaced by clock_gettime64,
> > clock_settime64, and utimensat_time64."
> >
> > Moreover, the stime has been even explicitly marked as obsolete [3].
> >
> >
> > From other discussion [4] - regarding the following system calls:
> >  time, stime, gettimeofday, settimeofday, adjtimex, nanosleep,
> > alarm, getitimer, setitimer, select, utime, utimes, futimesat, and
> >  {old,new}{l,f,}stat{,64}.
> >
> > "These all pass 32-bit time_t arguments on 32-bit
> >  architectures and are replaced by other interfaces (e.g. posix
> >  timers and clocks, statx). C libraries implementing 64-bit time_t
> > in 32-bit architectures have to implement the handles by wrapping
> >  around the newer interfaces."
> >
> >
> >
> >
> > Has something changed since then? Has any new idea for conversion
> > emerged?  
> 
> No, this has been the plan for many years now.

Ok.

> 
> > After observing the development of y2038 on playground [1], I can
> > deduce that new interfaces are only going to be supported and
> > converted (clock_settime64/clock_gettime64, etc.)
> >
> > Considering the above - would it be best to drop Y2038 support on 32
> > bit machines for old syscalls (stime and friends) and for some
> > others (settimeofday/gettimeofday) write Y2038 wrappers based on
> > new time kernel API (clock_gettime/settime) in the C library (i.e.
> > glibc)?  
> 
> There are multiple dimensions to what you are asking here:
> 
> - On the user space interface, the C library (glibc, musl,
> uclibc, ...) implements a set of interfaces for time management. The
>   set that is implemented here is defined by POSIX and other
>   standards and decided by the respective C library implementation.
>   All functions that get implemented here have to use the same
>   definition of time_t however, so if there is both a clock_gettime()
>   function and a time() function, they must either both use 32-bit
>   time_t or both must use 64-bit time_t. Both can be implemented
>   on top of any kernel interface for getting the time (time,
> gettimeofday, clock_gettime, clock_gettime64), but the only sensible
> implementation is to use clock_gettime64() in order to have the full
> range and resolution.

I see. I just would like to be sure that the "old" API calls (for
example the settimeofday, gettimeofday, stime, etc) are not recommended
(planned?) for conversion to have 64 bit interfaces (like
clock_{get|set}time).

> 
> - The kernel has a growing set of system calls, i.e. we tend to
>   only add new

Re: [PATCH v2] ARM: socfpga_defconfig: enable support for large block devices

[Andrey Zhizhikin]

Hello Dinh,

Just a short ping on this patch - do yo think you can accept this
patch and have it merged? I'd like to know whether it is planned to be
integrated, as it might be beneficial for a lot of socfpga users...

Thanks a lot!
-- 
Regards,
Andrey.

On Wed, Feb 27, 2019 at 5:50 PM Andrey Zhizhikin  wrote:
>
> Enable CONFIG_LBDAF, which is required by ext4 fs. This option could
> handle both ext3 and ext4, with ext4 requires this option to be enabled,
> otherwise the filesystem is mounted RO mode.
>
> Since the LBDAF is enabled by default for 32-bit systems, simply
> removing the current "not set" entry enables the support.
>
> Signed-off-by: Andrey Zhizhikin 
> ---
>  arch/arm/configs/socfpga_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/socfpga_defconfig 
> b/arch/arm/configs/socfpga_defconfig
> index 08d1b3e11d68..c96d93fb68c6 100644
> --- a/arch/arm/configs/socfpga_defconfig
> +++ b/arch/arm/configs/socfpga_defconfig
> @@ -21,7 +21,6 @@ CONFIG_NEON=y
>  CONFIG_OPROFILE=y
>  CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
> -# CONFIG_LBDAF is not set
>  # CONFIG_BLK_DEV_BSG is not set
>  CONFIG_NET=y
>  CONFIG_PACKET=y
> --
> 2.17.1
>

Re: [GIT PULL] Driver core patches for 5.1-rc1

[Arnd Bergmann]

On Thu, Mar 7, 2019 at 12:48 AM Linus Torvalds
 wrote:
> On Wed, Mar 6, 2019 at 2:33 AM Greg KH  wrote:
>
> I wonder why this wasn't seen in linux-next? Yes, the connection is
> odd, and maybe it's very compiler version dependent, but I do hope
> people react to new warnings. The kernel is entirely warning-free for
> me for an x86-64 allmodconfig build, and I want to keep it that way.

I saw it in linux-next and sent a patch the other day, similar to yours,
but with a less verbose changelog:
https://patchwork.kernel.org/patch/10838499/

Overall, I had not done regular randconfig testing since the start of
the year, and found 62 regressions that had crept in during that
period. There was no significant uptick in -Wmaybe-uninitialized
warnings, this is the only one I saw, so I'd classify this as random
change in behavior due to inlining differences rather than a systematic
issue.
(there was a noticeable change in other warnings, particularly a stack
size increase from the new structleak plugin changes, fix is coming).

 Arnd

Re: mainline/master boot bisection: v5.0-4854-g8dcd175bc3d5 on odroid-xu3

[Krzysztof Kozlowski]

On Thu, 7 Mar 2019 at 08:13, kernelci.org bot  wrote:
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis  *
> * that you may be involved with the breaking commit it has  *
> * found.  No manual investigation has been done to verify it,   *
> * and the root cause of the problem may be somewhere else.  *
> * Hope this helps!  *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> mainline/master boot bisection: v5.0-4854-g8dcd175bc3d5 on odroid-xu3
>
> Summary:
>   Start:  8dcd175bc3d5 Merge branch 'akpm' (patches from Andrew)
>   Details:https://kernelci.org/boot/id/5c8052c159b5146b7bfe6018
>   Plain log:  
> https://storage.kernelci.org//mainline/master/v5.0-4854-g8dcd175bc3d5/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.txt
>   HTML log:   
> https://storage.kernelci.org//mainline/master/v5.0-4854-g8dcd175bc3d5/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.html
>   Result: 0918f18c7179 crypto: s5p - add AES support for Exynos5433
>
> Checks:
>   revert: PASS
>   verify: PASS

Thanks bot!
It is already known and patch is waiting to be applied:
https://patchwork.kernel.org/patch/10835389/

Best regards,
Krzysztof

Re: [PATCH v2 10/20] x86: avoid W^X being broken during modules loading

[Borislav Petkov]

On Mon, Feb 11, 2019 at 08:42:51PM +0100, Borislav Petkov wrote:
> On Mon, Feb 11, 2019 at 11:27:03AM -0800, Nadav Amit wrote:
> > Is there any comment over static_cpu_has()? ;-)
> 
> Almost:
> 
> /*
>  * Static testing of CPU features.  Used the same as boot_cpu_has().
>  * These will statically patch the target code for additional
>  * performance.
>  */
> static __always_inline __pure bool _static_cpu_has(u16 bit)

Ok, I guess something like that along with converting the obvious slow
path callers to boot_cpu_has():

---
diff --git a/arch/x86/include/asm/cpufeature.h 
b/arch/x86/include/asm/cpufeature.h
index ce95b8cbd229..e25d11ad7a88 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -155,9 +155,12 @@ extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned 
int bit);
 #else
 
 /*
- * Static testing of CPU features.  Used the same as boot_cpu_has().
- * These will statically patch the target code for additional
- * performance.
+ * Static testing of CPU features. Used the same as boot_cpu_has(). It
+ * statically patches the target code for additional performance. Use
+ * static_cpu_has() only in fast paths, where every cycle counts. Which
+ * means that the boot_cpu_has() variant is already fast enough for the
+ * majority of cases and you should stick to using it as it is generally
+ * only two instructions: a RIP-relative MOV and a TEST.
  */
 static __always_inline __pure bool _static_cpu_has(u16 bit)
 {
diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index fa2c93cb42a2..c525b053b3b3 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -291,7 +291,7 @@ static inline void copy_xregs_to_kernel_booting(struct 
xregs_state *xstate)
 
WARN_ON(system_state != SYSTEM_BOOTING);
 
-   if (static_cpu_has(X86_FEATURE_XSAVES))
+   if (boot_cpu_has(X86_FEATURE_XSAVES))
XSTATE_OP(XSAVES, xstate, lmask, hmask, err);
else
XSTATE_OP(XSAVE, xstate, lmask, hmask, err);
@@ -313,7 +313,7 @@ static inline void copy_kernel_to_xregs_booting(struct 
xregs_state *xstate)
 
WARN_ON(system_state != SYSTEM_BOOTING);
 
-   if (static_cpu_has(X86_FEATURE_XSAVES))
+   if (boot_cpu_has(X86_FEATURE_XSAVES))
XSTATE_OP(XRSTORS, xstate, lmask, hmask, err);
else
XSTATE_OP(XRSTOR, xstate, lmask, hmask, err);
@@ -528,8 +528,7 @@ static inline void fpregs_activate(struct fpu *fpu)
  *  - switch_fpu_finish() restores the new state as
  *necessary.
  */
-static inline void
-switch_fpu_prepare(struct fpu *old_fpu, int cpu)
+static inline void switch_fpu_prepare(struct fpu *old_fpu, int cpu)
 {
if (static_cpu_has(X86_FEATURE_FPU) && old_fpu->initialized) {
if (!copy_fpregs_to_fpstate(old_fpu))
diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index 78778b54f904..a5464b8b6c46 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -175,7 +175,7 @@ static void fixup_cpu_id(struct cpuinfo_x86 *c, int node)
this_cpu_write(cpu_llc_id, node);
 
/* Account for nodes per socket in multi-core-module processors */
-   if (static_cpu_has(X86_FEATURE_NODEID_MSR)) {
+   if (boot_cpu_has(X86_FEATURE_NODEID_MSR)) {
rdmsrl(MSR_FAM10H_NODE_ID, val);
nodes = ((val >> 3) & 7) + 1;
}
diff --git a/arch/x86/kernel/cpu/aperfmperf.c b/arch/x86/kernel/cpu/aperfmperf.c
index 804c49493938..64d5aec24203 100644
--- a/arch/x86/kernel/cpu/aperfmperf.c
+++ b/arch/x86/kernel/cpu/aperfmperf.c
@@ -83,7 +83,7 @@ unsigned int aperfmperf_get_khz(int cpu)
if (!cpu_khz)
return 0;
 
-   if (!static_cpu_has(X86_FEATURE_APERFMPERF))
+   if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
return 0;
 
aperfmperf_snapshot_cpu(cpu, ktime_get(), true);
@@ -99,7 +99,7 @@ void arch_freq_prepare_all(void)
if (!cpu_khz)
return;
 
-   if (!static_cpu_has(X86_FEATURE_APERFMPERF))
+   if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
return;
 
for_each_online_cpu(cpu)
@@ -115,7 +115,7 @@ unsigned int arch_freq_get_on_cpu(int cpu)
if (!cpu_khz)
return 0;
 
-   if (!static_cpu_has(X86_FEATURE_APERFMPERF))
+   if (!boot_cpu_has(X86_FEATURE_APERFMPERF))
return 0;
 
if (aperfmperf_snapshot_cpu(cpu, ktime_get(), true))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index cb28e98a0659..95a5faf3a6a0 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1668,7 +1668,7 @@ static void setup_getcpu(int cpu)
unsigned long cpudata = vdso_encode_cpunode(cpu, 
early_cpu_to_node(cpu));
struct desc_struct d = { };
 
-   if (static_cpu_has(X86_FEATURE_RDTSCP))
+   if 

Re: [RFC PATCH v1 19/25] printk: introduce emergency messages

[Sergey Senozhatsky]

On (02/12/19 15:29), John Ogness wrote:
[..]
> +static bool console_can_emergency(int level)
> +{
> + struct console *con;
> +
> + for_each_console(con) {
> + if (!(con->flags & CON_ENABLED))
> + continue;
> + if (con->write_atomic && level < emergency_console_loglevel)
> + return true;
> + if (con->write && (con->flags & CON_BOOT))
> + return true;
> + }
> + return false;
> +}
> +
> +static void call_emergency_console_drivers(int level, const char *text,
> +size_t text_len)
> +{
> + struct console *con;
> +
> + for_each_console(con) {
> + if (!(con->flags & CON_ENABLED))
> + continue;
> + if (con->write_atomic && level < emergency_console_loglevel) {
> + con->write_atomic(con, text, text_len);
> + continue;
> + }
> + if (con->write && (con->flags & CON_BOOT)) {
> + con->write(con, text, text_len);
> + continue;
> + }
> + }
> +}
> +
> +static void printk_emergency(char *buffer, int level, u64 ts_nsec, u16 cpu,
> +  char *text, u16 text_len)
> +{
> + struct printk_log msg;
> + size_t prefix_len;
> +
> + if (!console_can_emergency(level))
> + return;
> +
> + msg.level = level;
> + msg.ts_nsec = ts_nsec;
> + msg.cpu = cpu;
> + msg.facility = 0;
> +
> + /* "text" must have PREFIX_MAX preceding bytes available */
> +
> + prefix_len = print_prefix(,
> +   console_msg_format & MSG_FORMAT_SYSLOG,
> +   printk_time, buffer);
> + /* move the prefix forward to the beginning of the message text */
> + text -= prefix_len;
> + memmove(text, buffer, prefix_len);
> + text_len += prefix_len;
> +
> + text[text_len++] = '\n';
> +
> + call_emergency_console_drivers(level, text, text_len);

So this iterates the console list and calls consoles' callbacks, but what
prevents console driver to be rmmod-ed under us?

CPU0CPU1

printk_emergency()  rmmod netcon
 call_emergency_console_drivers()   
  con_foo->flags & CON_ENABLED == 1

unregister_console(con_foo)
con_foo->flags &= 
~CON_ENABLED
__exit // con_foo gone ?
  con_foo->write()

We use console_lock()/console_trylock() in order to protect the list and
console drivers; but this brings scheduler to the picture, with all its
locks.

Or am I missing something?

-ss

Re: [RFC PATCH 2/2] ceph: quota: fix quota subdir mounts

[Yan, Zheng]

On Thu, Mar 7, 2019 at 2:21 AM Luis Henriques  wrote:
>
> "Yan, Zheng"  writes:
>
> > On Sat, Mar 2, 2019 at 3:13 AM Luis Henriques  wrote:
> >>
> >> The CephFS kernel client doesn't enforce quotas that are set in a
> >> directory that isn't visible in the mount point.  For example, given the
> >> path '/dir1/dir2', if quotas are set in 'dir1' and the mount is done in 
> >> with
> >>
> >>   mount -t ceph ::/dir1/ /mnt
> >>
> >> then the client can't access the 'dir1' inode from the quota realm dir2
> >> belongs to.
> >>
> >> This patch fixes this by simply doing an MDS LOOKUPINO Op and grabbing a
> >> reference to it (so that it doesn't disappear again).  This also requires 
> >> an
> >> extra field in ceph_snap_realm so that we know we have to release that
> >> reference when destroying the realm.
> >>
> >
> > This may cause circle reference if somehow an inode owned by snaprealm
> > get moved into mount subdir (other clients do rename).  how about
> > holding these inodes in mds_client?
>
> Ok, before proceeded any further I wanted to make sure that what you
> were suggesting was something like the patch below.  It simply keeps a
> list of inodes in ceph_mds_client until the filesystem is umounted,
> iput()ing them at that point.
>
yes,

> I'm sure I'm missing another place where the reference should be
> dropped, but I couldn't figure it out yet.  It can't be
> ceph_destroy_inode; drop_inode_snap_realm is a possibility, but what if
> the inode becomes visible in the meantime?  Well, I'll continue thinking
> about it.

why do you think we need to clean up the references at other place.
what problem you encountered.

Regards
Yan, Zheng
>
> Function get_quota_realm() should have a similar construct to lookup
> inodes.  But it's a bit more tricky, because ceph_quota_is_same_realm()
> requires snap_rwsem to be held for the 2 invocations of
> get_quota_realm.
>
> Cheers,
> --
> Luis
>
> From a429a4c167186781bd235a25d72be893baf9e029 Mon Sep 17 00:00:00 2001
> From: Luis Henriques 
> Date: Wed, 6 Mar 2019 17:58:04 +
> Subject: [PATCH] ceph: quota: fix quota subdir mounts (II)
>
> Signed-off-by: Luis Henriques 
> ---
>  fs/ceph/mds_client.c | 14 ++
>  fs/ceph/mds_client.h |  2 ++
>  fs/ceph/quota.c  | 34 ++
>  fs/ceph/super.h  |  2 ++
>  4 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
> index 163fc74bf221..72c5ce5e4209 100644
> --- a/fs/ceph/mds_client.c
> +++ b/fs/ceph/mds_client.c
> @@ -3656,6 +3656,8 @@ int ceph_mdsc_init(struct ceph_fs_client *fsc)
> mdsc->max_sessions = 0;
> mdsc->stopping = 0;
> atomic64_set(>quotarealms_count, 0);
> +   INIT_LIST_HEAD(>quotarealms_inodes_list);
> +   spin_lock_init(>quotarealms_inodes_lock);
> mdsc->last_snap_seq = 0;
> init_rwsem(>snap_rwsem);
> mdsc->snap_realms = RB_ROOT;
> @@ -3726,9 +3728,21 @@ static void wait_requests(struct ceph_mds_client *mdsc)
>   */
>  void ceph_mdsc_pre_umount(struct ceph_mds_client *mdsc)
>  {
> +   struct ceph_inode_info *ci;
> +
> dout("pre_umount\n");
> mdsc->stopping = 1;
>
> +   spin_lock(>quotarealms_inodes_lock);
> +   while(!list_empty(>quotarealms_inodes_list)) {
> +   ci = list_first_entry(>quotarealms_inodes_list,
> + struct ceph_inode_info,
> + i_quotarealms_inode_item);
> +   list_del(>i_quotarealms_inode_item);
> +   iput(>vfs_inode);
> +   }
> +   spin_unlock(>quotarealms_inodes_lock);
> +
> lock_unlock_sessions(mdsc);
> ceph_flush_dirty_caps(mdsc);
> wait_requests(mdsc);
> diff --git a/fs/ceph/mds_client.h b/fs/ceph/mds_client.h
> index 729da155ebf0..58968fb338ec 100644
> --- a/fs/ceph/mds_client.h
> +++ b/fs/ceph/mds_client.h
> @@ -329,6 +329,8 @@ struct ceph_mds_client {
> int stopping;  /* true if shutting down */
>
> atomic64_t  quotarealms_count; /* # realms with quota */
> +   struct list_headquotarealms_inodes_list;
> +   spinlock_t  quotarealms_inodes_lock;
>
> /*
>  * snap_rwsem will cover cap linkage into snaprealms, and
> diff --git a/fs/ceph/quota.c b/fs/ceph/quota.c
> index 9455d3aef0c3..7d4dec9eea47 100644
> --- a/fs/ceph/quota.c
> +++ b/fs/ceph/quota.c
> @@ -22,7 +22,16 @@ void ceph_adjust_quota_realms_count(struct inode *inode, 
> bool inc)
>  static inline bool ceph_has_realms_with_quotas(struct inode *inode)
>  {
> struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc;
> -   return atomic64_read(>quotarealms_count) > 0;
> +   struct super_block *sb = mdsc->fsc->sb;
> +
> +   if (atomic64_read(>quotarealms_count) > 0)
> +   return true;
> +   /* if root is the real CephFS root, we don't have quota realms */
> +   if 

Re: [PATCH v1] arch_topology: Make cpu_capacity sysfs node as ready-only

[Juri Lelli]

Hi,

On 06/03/19 20:57, Lingutla Chandrasekhar wrote:
> If user updates any cpu's cpu_capacity, then the new value is going to
> be applied to all its online sibling cpus. But this need not to be correct
> always, as sibling cpus (in ARM, same micro architecture cpus) would have
> different cpu_capacity with different performance characteristics.
> So updating the user supplied cpu_capacity to all cpu siblings
> is not correct.
> 
> And another problem is, current code assumes that 'all cpus in a cluster
> or with same package_id (core_siblings), would have same cpu_capacity'.
> But with commit '5bdd2b3f0f8 ("arm64: topology: add support to remove
> cpu topology sibling masks")', when a cpu hotplugged out, the cpu
> information gets cleared in its sibling cpus. So user supplied
> cpu_capacity would be applied to only online sibling cpus at the time.
> After that, if any cpu hot plugged in, it would have different cpu_capacity
> than its siblings, which breaks the above assumption.
> 
> So instead of mucking around the core sibling mask for user supplied
> value, use device-tree to set cpu capacity. And make the cpu_capacity
> node as read-only to know the assymetry between cpus in the system.
> 
> Signed-off-by: Lingutla Chandrasekhar 
> ---
>  drivers/base/arch_topology.c | 33 +
>  1 file changed, 1 insertion(+), 32 deletions(-)
> 
> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> index edfcf8d..d455897 100644
> --- a/drivers/base/arch_topology.c
> +++ b/drivers/base/arch_topology.c
> @@ -7,7 +7,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -51,37 +50,7 @@ static ssize_t cpu_capacity_show(struct device *dev,
>  static void update_topology_flags_workfn(struct work_struct *work);
>  static DECLARE_WORK(update_topology_flags_work, 
> update_topology_flags_workfn);
>  
> -static ssize_t cpu_capacity_store(struct device *dev,
> -   struct device_attribute *attr,
> -   const char *buf,
> -   size_t count)
> -{
> - struct cpu *cpu = container_of(dev, struct cpu, dev);
> - int this_cpu = cpu->dev.id;
> - int i;
> - unsigned long new_capacity;
> - ssize_t ret;
> -
> - if (!count)
> - return 0;
> -
> - ret = kstrtoul(buf, 0, _capacity);
> - if (ret)
> - return ret;
> - if (new_capacity > SCHED_CAPACITY_SCALE)
> - return -EINVAL;
> -
> - mutex_lock(_scale_mutex);
> - for_each_cpu(i, _topology[this_cpu].core_sibling)
> - topology_set_cpu_scale(i, new_capacity);
> - mutex_unlock(_scale_mutex);
> -
> - schedule_work(_topology_flags_work);
> -
> - return count;
> -}
> -
> -static DEVICE_ATTR_RW(cpu_capacity);
> +static DEVICE_ATTR_RO(cpu_capacity);

There are cases in which this needs to be RW, as recently discussed
https://lore.kernel.org/lkml/20181123135807.GA14964@e107155-lin/

IMHO, if the core_sibling assumption doesn't work in all cases, one
should be looking into fixing it, rather than making this RO.

Best,

- Juri

Re: [PATCH] Avoid that check_shl_overflow() triggers a compiler warning when building with W=1

[Leon Romanovsky]

On Wed, Mar 06, 2019 at 06:14:09PM -0800, Bart Van Assche wrote:
> On 3/6/19 5:24 PM, Jason Gunthorpe wrote:
> > On Wed, Mar 06, 2019 at 05:01:53PM -0800, Bart Van Assche wrote:
> > > This patch avoids that the following warning is reported when building
> > > the mlx5 driver with W=1:
> > >
> > > drivers/infiniband/hw/mlx5/qp.c: In function set_user_rq_size:
> > > ./include/linux/overflow.h:230:6: warning: comparison of unsigned 
> > > expression >= 0 is always true [-Wtype-limits]
> > > _s >= 0 && _s < 8 * sizeof(*d) ? _s : 0;  \
> > >^
> > > drivers/infiniband/hw/mlx5/qp.c:5820:6: note: in expansion of macro 
> > > check_shl_overflow
> > >if (check_shl_overflow(rwq->wqe_count, rwq->wqe_shift, >buf_size))
> > >^~
> > >
> > > Cc: Jason Gunthorpe 
> > > Cc: Leon Romanovsky 
> > > Cc: Rasmus Villemoes 
> > > Fixes: 0c66847793d1 ("overflow.h: Add arithmetic shift helper") # v4.19
> > > Signed-off-by: Bart Van Assche 
> > >   include/linux/overflow.h | 22 --
> > >   1 file changed, 20 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/linux/overflow.h b/include/linux/overflow.h
> > > index 40b48e2133cb..8afe0c0ada6f 100644
> > > +++ b/include/linux/overflow.h
> > > @@ -202,6 +202,24 @@
> > >   #endif /* COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW */
> > > +/*
> > > + * Evaluate a >= 0 without triggering a compiler warning if the type of a
> > > + * is an unsigned type.
> > > + */
> > > +#define is_positive(a) ({\
> > > + typeof(a) _minus_one = -1LL;\
> > > + typeof((a) + 0U) _sign_mask = _minus_one > 0 ? 0 :  \
> >
> > This is probably just is_signed_type(a)
>
> Hi Jason,
>
> I don't think that gcc accepts something like is_signed_type(typeof(a)) so
> I'm not sure that the is_signed_type() macro is useful in this context.
>
> > > + 1ULL << (8 * sizeof(a) - 1);\
> > > + \
> > > + ((a) & _sign_mask) == 0;\
> > This is the same sort of obfuscation that Leon was building, do you
> > think the & is better than his ==, >  version?
> >
> > Will gcc shortcircuit the warning if we write it as
> >
> > (is_signed_type(a) && a < 0)
> >
> > ?
>
> I have tested this patch. With this patch applied no warnings are reported
> while building the mlx5 driver and the tests in lib/test_overflow.c pass.

Bart,

My simple patch passes too :).

>
> Thanks,
>
> Bart.


signature.asc
Description: PGP signature

Re: [PATCH] Avoid that check_shl_overflow() triggers a compiler warning when building with W=1

[Rasmus Villemoes]

On 07/03/2019 03.14, Bart Van Assche wrote:
> On 3/6/19 5:24 PM, Jason Gunthorpe wrote:
>>>
>>> diff --git a/include/linux/overflow.h b/include/linux/overflow.h
>>> index 40b48e2133cb..8afe0c0ada6f 100644
>>> +++ b/include/linux/overflow.h
>>> @@ -202,6 +202,24 @@
>>>     #endif /* COMPILER_HAS_GENERIC_BUILTIN_OVERFLOW */
>>>   +/*
>>> + * Evaluate a >= 0 without triggering a compiler warning if the type
>>> of a
>>> + * is an unsigned type.
>>> + */
>>> +#define is_positive(a) ({    \

is_non_negative, please! positive means > 0. And perhaps it's better to
move these utility macros closer to the top of the file, together with
the other type/range helpers.

>>> +    typeof(a) _minus_one = -1LL;    \
>>> +    typeof((a) + 0U) _sign_mask = _minus_one > 0 ? 0 :    \
 This is probably just is_signed_type(a)
> 
> Hi Jason,
> 
> I don't think that gcc accepts something like is_signed_type(typeof(a))
> so I'm not sure that the is_signed_type() macro is useful in this context.

Of course it does, it is even already used exactly that way in overflow.h.

Nice hack, I can't come up with anything better ATM. So if you fix the
name and reuse is_signed_type instead of opencoding it you can add my ack.

>>> +    1ULL << (8 * sizeof(a) - 1);    \
>>> +    \
>>> +    ((a) & _sign_mask) == 0;    \
>>  
>> This is the same sort of obfuscation that Leon was building, do you
>> think the & is better than his ==, >  version?
>>
>> Will gcc shortcircuit the warning if we write it as
>>
>> (is_signed_type(a) && a < 0)
>>
>> ?

Unlikely, the Wtype-limits warning trigger at a very early stage of
parsing, so it's the mere presence of the a < 0 subexpression that
tickles it. So no amount of hiding it behind short-circuiting logic or
if() statements will help. See also the comment above
__signed_mul_overflow, where even code in the the untaken branch of a
__builtin_choose_expr() can trigger Wtype-limit.

> I have tested this patch. With this patch applied no warnings are
> reported while building the mlx5 driver and the tests in
> lib/test_overflow.c pass.

In cases like this it's good to be more explicit, i.e. "I've tested this
patch with gcc 6.5.4 and...", and even better of course if one does it
with several compiler versions. Please include the above paragraph +
compiler version info in the commit log.

Rasmus

mainline/master boot bisection: v5.0-5022-g542d0e583b7b on odroid-xu3

[kernelci.org bot]

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis  *
* that you may be involved with the breaking commit it has  *
* found.  No manual investigation has been done to verify it,   *
* and the root cause of the problem may be somewhere else.  *
* Hope this helps!  *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

mainline/master boot bisection: v5.0-5022-g542d0e583b7b on odroid-xu3

Summary:
  Start:  542d0e583b7b Merge tag 'devprop-5.1-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
  Details:https://kernelci.org/boot/id/5c806c1d59b5148945fe6019
  Plain log:  
https://storage.kernelci.org//mainline/master/v5.0-5022-g542d0e583b7b/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.txt
  HTML log:   
https://storage.kernelci.org//mainline/master/v5.0-5022-g542d0e583b7b/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.html
  Result: 0918f18c7179 crypto: s5p - add AES support for Exynos5433

Checks:
  revert: PASS
  verify: PASS

Parameters:
  Tree:   mainline
  URL:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  Branch: master
  Target: odroid-xu3
  CPU arch:   arm
  Lab:lab-collabora
  Compiler:   gcc-7
  Config: exynos_defconfig
  Test suite: boot

Breaking commit found:

---
commit 0918f18c7179e8cdf718d01531a81b28130b4217
Author: Kamil Konieczny 
Date:   Fri Feb 22 13:21:44 2019 +0100

crypto: s5p - add AES support for Exynos5433

Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kamil Konieczny 
Signed-off-by: Herbert Xu 

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 8d0afdc220ff..f4e625cf53ca 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -232,6 +232,7 @@
  * struct samsung_aes_variant - platform specific SSS driver data
  * @aes_offset: AES register offset from SSS module's base.
  * @hash_offset: HASH register offset from SSS module's base.
+ * @clk_names: names of clocks needed to run SSS IP
  *
  * Specifies platform specific configuration of SSS module.
  * Note: A structure for driver specific platform data is used for future
@@ -240,6 +241,7 @@
 struct samsung_aes_variant {
unsigned intaes_offset;
unsigned inthash_offset;
+   const char  *clk_names[];
 };
 
 struct s5p_aes_reqctx {
@@ -296,6 +298,7 @@ struct s5p_aes_ctx {
 struct s5p_aes_dev {
struct device   *dev;
struct clk  *clk;
+   struct clk  *pclk;
void __iomem*ioaddr;
void __iomem*aes_ioaddr;
int irq_fc;
@@ -384,11 +387,19 @@ struct s5p_hash_ctx {
 static const struct samsung_aes_variant s5p_aes_data = {
.aes_offset = 0x4000,
.hash_offset= 0x6000,
+   .clk_names  = { "secss", },
 };
 
 static const struct samsung_aes_variant exynos_aes_data = {
.aes_offset = 0x200,
.hash_offset= 0x400,
+   .clk_names  = { "secss", },
+};
+
+static const struct samsung_aes_variant exynos5433_slim_aes_data = {
+   .aes_offset = 0x400,
+   .hash_offset= 0x800,
+   .clk_names  = { "pclk", "aclk", },
 };
 
 static const struct of_device_id s5p_sss_dt_match[] = {
@@ -400,6 +411,10 @@ static const struct of_device_id s5p_sss_dt_match[] = {
.compatible = "samsung,exynos4210-secss",
.data = _aes_data,
},
+   {
+   .compatible = "samsung,exynos5433-slim-sss",
+   .data = _slim_aes_data,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
@@ -2218,18 +2233,39 @@ static int s5p_aes_probe(struct platform_device *pdev)
return PTR_ERR(pdata->ioaddr);
}
 
-   pdata->clk = devm_clk_get(dev, "secss");
+   pdata->clk = devm_clk_get(dev, variant->clk_names[0]);
if (IS_ERR(pdata->clk)) {
-   dev_err(dev, "failed to find secss clock source\n");
+   dev_err(dev, "failed to find secss clock %s\n",
+   variant->clk_names[0]);
return -ENOENT;
}
 
err = clk_prepare_enable(pdata->clk);
if (err < 0) {
-   dev_err(dev, "Enabling SSS clk failed, err %d\n", err);
+   dev_err(dev, "Enabling clock %s failed, err %d\n",
+   variant->clk_names[0], err);
return err;
}
 
+   if (variant->clk_names[1]) {
+   pdata->pclk = devm_clk_get(dev, variant->clk_names[1]);
+ 

mainline/master boot bisection: v5.0-4854-g8dcd175bc3d5 on odroid-xu3

[kernelci.org bot]

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis  *
* that you may be involved with the breaking commit it has  *
* found.  No manual investigation has been done to verify it,   *
* and the root cause of the problem may be somewhere else.  *
* Hope this helps!  *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

mainline/master boot bisection: v5.0-4854-g8dcd175bc3d5 on odroid-xu3

Summary:
  Start:  8dcd175bc3d5 Merge branch 'akpm' (patches from Andrew)
  Details:https://kernelci.org/boot/id/5c8052c159b5146b7bfe6018
  Plain log:  
https://storage.kernelci.org//mainline/master/v5.0-4854-g8dcd175bc3d5/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.txt
  HTML log:   
https://storage.kernelci.org//mainline/master/v5.0-4854-g8dcd175bc3d5/arm/exynos_defconfig/gcc-7/lab-collabora/boot-exynos5422-odroidxu3.html
  Result: 0918f18c7179 crypto: s5p - add AES support for Exynos5433

Checks:
  revert: PASS
  verify: PASS

Parameters:
  Tree:   mainline
  URL:git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  Branch: master
  Target: odroid-xu3
  CPU arch:   arm
  Lab:lab-collabora
  Compiler:   gcc-7
  Config: exynos_defconfig
  Test suite: boot

Breaking commit found:

---
commit 0918f18c7179e8cdf718d01531a81b28130b4217
Author: Kamil Konieczny 
Date:   Fri Feb 22 13:21:44 2019 +0100

crypto: s5p - add AES support for Exynos5433

Add AES crypto HW acceleration for Exynos5433, with the help of SlimSSS IP.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Kamil Konieczny 
Signed-off-by: Herbert Xu 

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 8d0afdc220ff..f4e625cf53ca 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -232,6 +232,7 @@
  * struct samsung_aes_variant - platform specific SSS driver data
  * @aes_offset: AES register offset from SSS module's base.
  * @hash_offset: HASH register offset from SSS module's base.
+ * @clk_names: names of clocks needed to run SSS IP
  *
  * Specifies platform specific configuration of SSS module.
  * Note: A structure for driver specific platform data is used for future
@@ -240,6 +241,7 @@
 struct samsung_aes_variant {
unsigned intaes_offset;
unsigned inthash_offset;
+   const char  *clk_names[];
 };
 
 struct s5p_aes_reqctx {
@@ -296,6 +298,7 @@ struct s5p_aes_ctx {
 struct s5p_aes_dev {
struct device   *dev;
struct clk  *clk;
+   struct clk  *pclk;
void __iomem*ioaddr;
void __iomem*aes_ioaddr;
int irq_fc;
@@ -384,11 +387,19 @@ struct s5p_hash_ctx {
 static const struct samsung_aes_variant s5p_aes_data = {
.aes_offset = 0x4000,
.hash_offset= 0x6000,
+   .clk_names  = { "secss", },
 };
 
 static const struct samsung_aes_variant exynos_aes_data = {
.aes_offset = 0x200,
.hash_offset= 0x400,
+   .clk_names  = { "secss", },
+};
+
+static const struct samsung_aes_variant exynos5433_slim_aes_data = {
+   .aes_offset = 0x400,
+   .hash_offset= 0x800,
+   .clk_names  = { "pclk", "aclk", },
 };
 
 static const struct of_device_id s5p_sss_dt_match[] = {
@@ -400,6 +411,10 @@ static const struct of_device_id s5p_sss_dt_match[] = {
.compatible = "samsung,exynos4210-secss",
.data = _aes_data,
},
+   {
+   .compatible = "samsung,exynos5433-slim-sss",
+   .data = _slim_aes_data,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, s5p_sss_dt_match);
@@ -2218,18 +2233,39 @@ static int s5p_aes_probe(struct platform_device *pdev)
return PTR_ERR(pdata->ioaddr);
}
 
-   pdata->clk = devm_clk_get(dev, "secss");
+   pdata->clk = devm_clk_get(dev, variant->clk_names[0]);
if (IS_ERR(pdata->clk)) {
-   dev_err(dev, "failed to find secss clock source\n");
+   dev_err(dev, "failed to find secss clock %s\n",
+   variant->clk_names[0]);
return -ENOENT;
}
 
err = clk_prepare_enable(pdata->clk);
if (err < 0) {
-   dev_err(dev, "Enabling SSS clk failed, err %d\n", err);
+   dev_err(dev, "Enabling clock %s failed, err %d\n",
+   variant->clk_names[0], err);
return err;
}
 
+   if (variant->clk_names[1]) {
+   pdata->pclk = devm_clk_get(dev, variant->clk_names[1]);
+   if (IS_ERR(pdata->pclk)) {
+  

[PATCH] [RFC] spi: pxa2xx: Do cs if restart the SSP during pxa2xx_spi_transfer_one()

[xiao jin]

The spi-pxa2xx can't read and write data correctly on our board.
The pxa_ssp_type is LPSS_BXT_SSP in our case.

With more debug we find that it's related to restart the SPP
during pxa2xx_spi_transfer_one().

In the normal case the spi_transfer_one_message() calls spi-pxa2xx
cs_assert before transferring one message. After completing the
transfer it calls spi-pxa2xx cs_deassert. The spi-pxa2xx works
well.

But in some other case pxa2xx_spi_unprepare_transfer() is called
that clears SSCR0_SSE bit before the next transfer. In the next
transfer the spi-pxa2xx driver will restart the SSP as the SSE
bit is cleared. The cs_assert before the SSP restart can't ensure
spi-pxa2xx work well.

The patch is to do cs again if spi-pxa2xx restar the SSP during
pxa2xx_spi_transfer_one()

Signed-off-by: xiao jin 
Signed-off-by: he, bo 
---
 drivers/spi/spi-pxa2xx.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 14f4ea59caff..1a2ea46858d9 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -928,6 +928,7 @@ static int pxa2xx_spi_transfer_one(struct spi_controller 
*master,
u32 cr1;
int err;
int dma_mapped;
+   bool need_cs_change = false;
 
/* Check if we can DMA this transfer */
if (transfer->len > MAX_DMA_LEN && chip->enable_dma) {
@@ -1056,6 +1057,11 @@ static int pxa2xx_spi_transfer_one(struct spi_controller 
*master,
if ((pxa2xx_spi_read(drv_data, SSCR0) != cr0)
|| (pxa2xx_spi_read(drv_data, SSCR1) & change_mask)
!= (cr1 & change_mask)) {
+   /* It needs to deassert the chip selection
+* firstly before restart the SPP */
+   need_cs_change = true;
+   cs_deassert(spi);
+
/* stop the SSP, and update the other bits */
pxa2xx_spi_write(drv_data, SSCR0, cr0 & ~SSCR0_SSE);
if (!pxa25x_ssp_comp(drv_data))
@@ -1070,6 +1076,8 @@ static int pxa2xx_spi_transfer_one(struct spi_controller 
*master,
pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
}
 
+   if (need_cs_change)
+   cs_assert(spi);
/*
 * Release the data by enabling service requests and interrupts,
 * without changing any mode bits
-- 
2.21.0

RE: [PATCH v4 6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer.

[Pawel Laszczak]

Hi,

>Hi,
>
>On 21/02/2019 09:14, Felipe Balbi wrote:
>>
>> Hi,
>>
>> (please break your emails at 80-columns)
>>
>> Pawel Laszczak  writes:
> One more thing. Workaround has implemented algorithm that decide for which
> endpoint it should be enabled.  e.g for composite device MSC+NCM+ACM it
> should work only for ACM OUT endpoint.
>

 If ACM driver didn't queue the request for ACM OUT endpoint, why does the
 controller accept the data at all?

 I didn't understand why we need a workaround for this. It should be 
 standard
 behaviour to NAK data if function driver didn't request for all endpoints.
>>>
>>> Yes, I agree with you. Controller shouldn’t accept such packet. As I know 
>>> this
>>> behavior will be fixed in RTL.
>>>
>>> But I assume that some older version of this controller are one the market,
>>> and driver should work correct with them.
>>>
>>> In the feature this workaround can be limited only to selected controllers.
>>>
>>> Even now I assume that it can be enabled/disabled by module parameter.
>>
>> no module parameters, please. Use revision detection in runtime.
>>
>
>This is about whether to enable or disable the workaround.
>By default we don't want this workaround to be enabled.
>
>I'm debating whether we should have this workaround at all or not.
>
>It has the following problems.
>
>1) It ACKs packets even when gadget end is not ready to accept the transfers.
>2) It stores these packets in a temporary buffer and then pushes them to the
>gadget driver whenever the gadget driver is ready to process the data.
>3) Since the gadget driver can become ready at an indefinite time in the
>future, it poses 2 problems:
> a) It is sending stale data to the sink. (problematic at next protocol level?)
> b) If this temporary buffer runs out we still hit the lock up issue.
>
>I think the right solution is to make sure that the gadget driver is always
>reading all the enabled OUT endpoints *or* (keep the OUT endpoints disabled
>if gadget driver is not ready to process OUT transfers).

If driver disable endpoint then it not answer for packets from host. 
It will result that host reset the device, so I can't disable such endpoints. 

Other good solution is to change ACM driver in a way that it sends requests 
to controller driver after enabling endpoint. The class driver could decide 
what should do with such not expected packets. It could delete all or e.g 
keep only few last packets. 

This issue will be fixed in RTL but maybe driver should be compatible with 
previous 
controller’s version.

By default, this workaround will be disabled or will depend on controller 
version.  
>
>cheers,
>-roger
>--
>Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Cheers,
Pawel

Re: [PATCH] MAINTAINERS: Include mlxreg.h in Mellanox Platform Driver files

[Andy Shevchenko]

On Wed, Mar 06, 2019 at 09:50:32PM -0800, Darren Hart (VMware) wrote:
> Avoid conflicts from other subsystems by including the header with the
> rest of the driver files.
> 

Acked-by: Andy Shevchenko 

> Cc: Andy Shevchenko 
> Cc: Vadim Pasternak 
> Signed-off-by: Darren Hart (VMware) 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 51029a425dbe..eb0b9aba4802 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9711,6 +9711,7 @@ M:  Vadim Pasternak 
>  L:   platform-driver-...@vger.kernel.org
>  S:   Supported
>  F:   drivers/platform/mellanox/
> +F:   include/linux/platform_data/mlxreg.h
>  
>  MELLANOX MLX4 core VPI driver
>  M:   Tariq Toukan 
> -- 
> 2.17.2
> 
> 
> -- 
> Darren Hart
> VMware Open Source Technology Center

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/3] x86: apuv2: fix input dependencies

[Darren Hart]

On Thu, Mar 07, 2019 at 01:10:13AM +0100, Enrico Weigelt, metux IT consult 
wrote:
> On 05.03.19 14:56, Andy Shevchenko wrote:
> > 
> > Darren gave a talk about merging kernel configs to get something like
> > you want to.
> > This tool is quite long already lying around. merge_config.sh in your
> > kernel source tree.
> 
> Yes, that's similar to how some distros (eg. yocto) do it.
> 

I wrote merge_config.sh to replace and simplify some of the yocto
tooling. With merge_config upstream, Yocto now uses it directly.

> But my requirements are a bit more complex:
> 
> In my final meta-config, I just wanna say:
> 
> * i have board A (possibly multiple boards)
> * i need features X, Y, Z (eg. eth, display, can, ext4, acl, ...)
> 
> And that shall be all to generate a minimal config for exactly those
> requirements.

That's also the goal of the Yocto configuration fragments, and is
possible with merge_config with a set of defined fragments.

> 
> Doing that by just putting config snippets together, quickly turns into
> a maintenance hell. At least you'd need recursive dependencies and some
> if/else logic.
> 
> That's why I've written kmct:
> 
> https://github.com/metux/kmct

I had a look, the README could benefit from a basic usage example.
Digging through it further, it appears that you are creating yaml files
which contain CONFIGs. The problem with this in my opinion is these are
kernel version specific, so you know have a lot of boiler plate yaml
wrapping kernel version specific CONFIG options which will slowly get
out of sync over time. This is the usual argument for keeping config
fragments together with the kernel - and why we do that in arch/*/config
for example.

Perhaps I'm missing your desired workflow though. I tend to find the
options I need and record them in a fragment, and save it off for later
to quickly be able to "make defconfig fragA.config fragB.config" etc. Is
what you're trying to do different?

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v1] Bluetooth: hci_qca: Give enough time to ROME controller to bootup.

[rjliao]

在 2019-03-07 14:49，Balakrishna Godavarthi 写道：

Hi Stepen,

On 2019-03-07 04:03, Stephen Boyd wrote:

Quoting Balakrishna Godavarthi (2019-03-06 08:21:13)

This patch enables enough time to ROME controller to bootup
after we bring the enable ping out of reset.

Signed-off-by: Balakrishna Godavarthi 
---


Any Fixes tag? And maybe some more explanation or background on where
150 ms sleep comes from would be useful. Was it determined
experimentally or did it come from a datasheet somewhere? Does the 
time

differ between boards?

[Bala]: this was observed in our stress testing and even the CHIP 
firmware team

confirmed that BT chip required at least 150 ms to boot up.

@Rocky to confirm my statement.


 drivers/bluetooth/hci_qca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c 
b/drivers/bluetooth/hci_qca.c

index 237aea34b69f..1953b13511e7 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -508,6 +508,8 @@ static int qca_open(struct hci_uart *hu)
qcadev = serdev_device_get_drvdata(hu->serdev);
if (qcadev->btsoc_type != QCA_WCN3990) {
gpiod_set_value_cansleep(qcadev->bt_en, 1);
+   /* Controller needs time to bootup. */
+   msleep(150);
} else {
hu->init_speed = qcadev->init_speed;
hu->oper_speed = qcadev->oper_speed;


Yes,ROME firmware needs 150ms to boot up after toggle the BT_EN pin.

Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread

[Sergey Senozhatsky]

On (03/07/19 15:41), Sergey Senozhatsky wrote:
> This sounds concerning. IMHO, netconsole is too important to rely
> on preemptible printk and scheduler. Especially those netcons which
> run in "report only when oops_in_progress" mode. Sometimes netconsole
> is the fastest console available, but preemptible printk may turn it
> into the slowest one.

+ oops may end by the time kthread becomes active.

-ss

Re: [PATCH v1] Bluetooth: hci_qca: Give enough time to ROME controller to bootup.

[Balakrishna Godavarthi]

Hi Stepen,

On 2019-03-07 04:03, Stephen Boyd wrote:

Quoting Balakrishna Godavarthi (2019-03-06 08:21:13)

This patch enables enough time to ROME controller to bootup
after we bring the enable ping out of reset.

Signed-off-by: Balakrishna Godavarthi 
---


Any Fixes tag? And maybe some more explanation or background on where
150 ms sleep comes from would be useful. Was it determined
experimentally or did it come from a datasheet somewhere? Does the time
differ between boards?

[Bala]: this was observed in our stress testing and even the CHIP 
firmware team

confirmed that BT chip required at least 150 ms to boot up.

@Rocky to confirm my statement.


 drivers/bluetooth/hci_qca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 237aea34b69f..1953b13511e7 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -508,6 +508,8 @@ static int qca_open(struct hci_uart *hu)
qcadev = serdev_device_get_drvdata(hu->serdev);
if (qcadev->btsoc_type != QCA_WCN3990) {
gpiod_set_value_cansleep(qcadev->bt_en, 1);
+   /* Controller needs time to bootup. */
+   msleep(150);
} else {
hu->init_speed = qcadev->init_speed;
hu->oper_speed = qcadev->oper_speed;


--
Regards
Balakrishna.

Re: [PATCH] spi-pxa2xx.c: modify the chip selection timing when spi transfer

[Xiao, Jin]

Hi Jarkko,

On 3/6/2019 3:52 PM, Jarkko Nikula wrote:

Hi

On 3/6/19 5:05 AM, xiao jin wrote:

From: "he, bo" 

We find spi can't work on board. More debug shows it's related
to the following patch that changed the chip selection assert and
deassert timing.


^^ timing caught my attention. More below.

@@ -610,6 +596,7 @@ static void int_transfer_complete(struct 
driver_data *drv_data)

  if (!pxa25x_ssp_comp(drv_data))
  pxa2xx_spi_write(drv_data, SSTO, 0);
  +    cs_deassert(drv_data);
  spi_finalize_current_transfer(drv_data->master);


This

@@ -1070,6 +1057,7 @@ static int pxa2xx_spi_transfer_one(struct 
spi_controller *master,

  pxa2xx_spi_write(drv_data, SSTO, chip->timeout);
  }
  +    cs_assert(drv_data);


and this is not correct with core message loop. It will cause the chip 
select is toggled with each transfer in PIO mode. If there is no 
cs_change flag set then there shouldn't be CS toggling between the 
transfers if SPI message consists of multiple transfers.


More over this patch also will regress with DMA mode since there won't 
be CS deassert at all.


Timing reminded me I've seen two cases where there was a timing 
related glitch in CS output:


d0283eb2dbc1 ("spi: pxa2xx: Add output control for multiple Intel LPSS 
chip selects")

7a8d44bc89e5 ("spi: pxa2xx: Fix too early chipselect deassert")

Do you have a possibility to measure with an oscilloscope what goes 
wrong with the CS after d5898e19c0d7 ("spi: pxa2xx: Use core message 
processing loop")?


Can you share your setup if I can reproduce it here? E.g. SPI clock 
frequency, single or multiple CS, frequency of occurrence, etc


In our setup the pxa_ssp_type is LPSS_BXT_SSP.  With more debug we find 
that the problem is caused in the case of "restart the SSP" when 
pxa2xx_spi_transfer_one.


We will send another RFC patch.

Thanks.

Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

[Alexandre Oliva]

On Feb 17, 2019, "Maciej W. Rozycki"  wrote:

>  Is there an MMIO completion barrier missing there somewhere by any chance 
> causing an IRQ that has been handled already to be redelivered because an 
> MMIO write meant to clear the IRQ at its origin at handler's completion 
> has not reached its destination before interrupts have been reenabled in 
> the issuing CPU?  Just a thought.

I've finally got a chance to bisect the IRQ14 (nobody cared) regression
on my yeeloong.  It took me to MIPS: Enforce strong ordering for MMIO
accessors (commit 3d474dacae72ac0f28228b328cfa953b05484b7f).

I've only just started trying to figure out what exactly in the change
leads to problems.  So far, I've determined that changing both uses of
__BUILD_IOPORT_SINGLE so that barrier is passed as 0 rather than 1
removes the undesirable effects, both on top of that patch, and on top
of v5.0:

 #define __BUILD_IOPORT_PFX(bus, bwlq, type)\
-   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)   \
-   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
+   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0,)   \
+   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 0, 0, _p)
 

Since the barriers didn't seem to be a problem for __BUILD_MEMORY_PFX, I
figured I'd try to enable barriers in the __mem_ variants, but leave
them alone for io, and that worked (without hitting the IRQ14 issue) at
least on the yeeloong:

diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 845fbbc7a2e34..0a3a327d4e764 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -467,13 +467,13 @@ BUILDIO_MEM(w, u16)
 BUILDIO_MEM(l, u32)
 BUILDIO_MEM(q, u64)
 
-#define __BUILD_IOPORT_PFX(bus, bwlq, type)\
-   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0,)   \
-   __BUILD_IOPORT_SINGLE(bus, bwlq, type, 1, 0, _p)
+#define __BUILD_IOPORT_PFX(bus, bwlq, type, barrier)   \
+   __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0,) \
+   __BUILD_IOPORT_SINGLE(bus, bwlq, type, barrier, 0, _p)
 
 #define BUILDIO_IOPORT(bwlq, type) \
-   __BUILD_IOPORT_PFX(, bwlq, type)\
-   __BUILD_IOPORT_PFX(__mem_, bwlq, type)
+   __BUILD_IOPORT_PFX(, bwlq, type, 0) \
+   __BUILD_IOPORT_PFX(__mem_, bwlq, type, 1)
 
 BUILDIO_IOPORT(b, u8)
 BUILDIO_IOPORT(w, u16)

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free! FSF Latin America board member
GNU Toolchain EngineerFree Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread

[Sergey Senozhatsky]

On (03/06/19 23:22), John Ogness wrote:
> On 2019-03-06, Petr Mladek  wrote:
> >> _Both_ categories are important for the user, but their requirements
> >> are different:
> >> 
> >>informational: non-disturbing
> >>emergency: reliable
> >
> > Isn't this already handled by the console_level?
> >
> > The informational messages can be reliably read via syslog, /dev/kmsg.
> > They are related to the normal works when the system works well.
> >
> > The emergency messages (errors, warnings) are printed in emergency
> > situations. They are printed as reliably as possible to the console
> > because the userspace might not be reliable enough.
> 
> I've never viewed console_level this way. _If_ console_level really is
> supposed to define the emergency/informational boundary, all
> informational messages are supposed to be handled by userspace, and
> console printing's main objective is reliability... then I would change
> my proposal such that:

OK, you guys are ahead of me.

FB folks want to have a per-console sysfs knob to dynamically adjust
loglevel on each console. The use case is to temporarily set loglevel
to, say, debug on fast consoles, gather some data/logs, set loglevel
back to less verbose afterwards.

Preserving the existing loglevel behaviour looks right to me.

> - if a console supports write_atomic(), _all_ console printing for that
>   console would use write_atomic()

Sounds right.
But Big-Konsole-Lock looks suspicious.

> - only consoles without write_atomic() will be printing via the
>   printk-kthread(s)
> 
> IMO, for consoles with write_atomic(), this would increase reliability
> over the current mainline implementation. It would also simplify
> write_atomic() implementations because they would no longer need to
> synchronize against write().

[..]
> For those consoles that cannot implement write_atomic() (vt and
> netconsole come to mind), or as a transition period until remaining
> console drivers have implemented write_atomic(), these would use the
> "fallback" of printing fully preemptively in their own kthread using
> write().

This sounds concerning. IMHO, netconsole is too important to rely
on preemptible printk and scheduler. Especially those netcons which
run in "report only when oops_in_progress" mode. Sometimes netconsole
is the fastest console available, but preemptible printk may turn it
into the slowest one.

-ss

Re: [PATCH] kbuild: add workaround for Debian make-kpkg

[Ben Hutchings]

On Thu, 2019-03-07 at 13:03 +0900, Masahiro Yamada wrote:
[...]
> If make-kpkg will still be included in the future Debian releases,
> I'd like to change make-kpkg to make it work more reliably.
> 
> 
> The git URL in the control file
> "https://anonscm.debian.org/git/users/srivasta/debian/kernel-package.git;
> seems stale.
> 
> Anyway, I found it in a new place:
> 
> $ git clone  https://salsa.debian.org/srivasta/kernel-package
> 
> 
> Hmm, the last commit was three years ago.
> 
> So, it is almost unmaintained, I guess...
[...]

Yes, though there was a more recent bug fix by another Debian
developer:
https://tracker.debian.org/news/857223/accepted-kernel-package-13018nmu1-source-into-unstable/

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



signature.asc
Description: This is a digitally signed message part

Re: [PATCH 4/4] iommu/vt-d: Remove lazy allocation of domains

[Lu Baolu]

Hi James,

On 3/7/19 2:08 AM, James Sewart wrote:

-   /*
-* For each rmrr
-*   for each dev attached to rmrr
-*   do
-* locate drhd for dev, alloc domain for dev
-* allocate free domain
-* allocate page table entries for rmrr
-* if context not allocated for bus
-*   allocate and init context
-*   set present in root table for this bus
-* init context with domain, translation etc
-*endfor
-* endfor
-*/
-   pr_info("Setting RMRR:\n");
-   for_each_rmrr_units(rmrr) {
-   /* some BIOS lists non-exist devices in DMAR table. */
-   for_each_active_dev_scope(rmrr->devices, rmrr->devices_cnt,
- i, dev) {
-   ret = iommu_prepare_rmrr_dev(rmrr, dev);
-   if (ret)
-   pr_err("Mapping reserved region failed\n");
-   }
-   }
-
-   iommu_prepare_isa();

Why do you want to remove this segment of code?

This will only work if the lazy allocation of domains exists, these
mappings will disappear once a default domain is attached to a device and
then remade by iommu_group_create_direct_mappings. This code is redundant
and removing it allows us to remove all the lazy allocation logic.

No exactly.

We need to setup the rmrr mapping before enabling dma remapping,
otherwise, there will be a window after dma remapping enabling and
rmrr getting mapped, during which people might see dma faults.

Do you think this patch instead should be a refactoring to simplify this 
initial domain setup before the default domain takes over? It seems like 
duplicated effort to have both lazy allocated domains and externally managed 
domains. We could allocate a domain here for any devices with RMRR and call 
get_resv_regions to avoid duplicating RMRR loop.



Agree. We should replace the lazy allocated domains with default domain
in a clean way. Actually, your patches look great to me. But I do think
we need further cleanups. The rmrr code is one example, and the identity
domain (si_domain) is another.

Do you mind if I work on top of your patches for further cleanups and
sign off a v2 together with you?

Best regards,
Lu Baolu

Re: [PATCH] powerpc: silence unused-but-set-variable warnings

[Christophe Leroy]

On 03/07/2019 03:48 AM, Qian Cai wrote:

pte_unmap() compiles away on some powerpc platforms, so silence the
warnings below by using the argument to pte_unmap() as a nop. Also, fix
checkpatch.pl warnings "Single statement macros should not use a do {}
while (0) loop".

mm/memory.c: In function 'copy_pte_range':
mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
[-Wunused-but-set-variable]
mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
[-Wunused-but-set-variable]
mm/madvise.c: In function 'madvise_free_pte_range':
mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
mm/swap_state.c: In function 'swap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]

Signed-off-by: Qian Cai 
---
  arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
  arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 868fcaf56f6b..ec00ce6dd312 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1006,7 +1006,7 @@ extern struct page *pgd_page(pgd_t pgd);
(((pte_t *) pmd_page_vaddr(*(dir))) + pte_index(addr))
  
  #define pte_offset_map(dir,addr)	pte_offset_kernel((dir), (addr))

-#define pte_unmap(pte) do { } while(0)
+#define pte_unmap(pte) (void)(pte)


I think it would be better with a static inline

--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -205,7 +205,8 @@ static inline void pgd_set(pgd_t *pgdp, unsigned 
long val)
   (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & 
(PTRS_PER_PTE - 1)))


 #define pte_offset_map(dir,addr)   pte_offset_kernel((dir), (addr))
-#define pte_unmap(pte) do { } while(0)
+
+static inline void pte_unmap(pte_t *pte) { }

 /* to find an entry in a kernel page-table-directory */
 /* This now only contains the vmalloc pages */


Christophe

  
  /* to find an entry in a kernel page-table-directory */

  /* This now only contains the vmalloc pages */
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h 
b/arch/powerpc/include/asm/nohash/64/pgtable.h
index e77ed9761632..103071afab3d 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -205,7 +205,7 @@ static inline void pgd_set(pgd_t *pgdp, unsigned long val)
(((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & 
(PTRS_PER_PTE - 1)))
  
  #define pte_offset_map(dir,addr)	pte_offset_kernel((dir), (addr))

-#define pte_unmap(pte) do { } while(0)
+#define pte_unmap(pte) (void)(pte)
  
  /* to find an entry in a kernel page-table-directory */

  /* This now only contains the vmalloc pages */

[GIT PULL] first round of SCSI updates for the 5.0+ merge window

[James Bottomley]

This is mostly update of the usual drivers: arcmsr, qla2xxx, lpfc,
hisi_sas, target/iscsi and target/core.  Additionally Christoph
refactored gdth as part of the dma changes.  The major mid-layer change
this time is the removal of bidi commands and with them the whole of
the osd/exofs driver and filesystem.  This is a major simplification
for block and mq in particular.

Additionally, there are four existing and one potential conflict:

- The unpulled block tree updates the removed osd driver

- 750afb08ca71 cross-tree: phase out dma_zalloc_coherent() conflicts
with the arcmsr update.  The fix is simple: go with our version

The remaining conflicts are internal between updates we supplied in our
fixes branches and changes made to the misc branch:

- hisi_sas_v3_hw.c: This is the nastiest: the fix to move the
protection parameters (7bb25a89aad2) conflicts with the DIX feature
addition (b3cce125cb1e).  The resolution is to make sure the DIX
enablement follows the move of the prot_mask check in
hisi_sas_v3_probe().

- lpfc_nvme.c: the fix to avoid hang/use after free (7961cba6f7d8)
conflicts with moving the stats to HW queue structures (4c47efc140fa). 
The resolution a simple combination of both patches.

- qla_init.c: The fix for the panic after free (388a49959ee4) conflicts
with move marker behind QPair (9eb9c6dc3ab0).  The fix is a straight
combination plus the transformation of sp->fcport->loop_id to fcport-
>loop_id to preserve the panic fix.

I've put the resolution in the linus-resolved branch of the scsi tree
for you to see and also attached the --cc diff below.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-misc

The short changelog is:

Anil Gurumurthy (1):
  scsi: qla2xxx: Add support for setting port speed

Avri Altman (4):
  scsi: ufs-bsg: Allow reading descriptors
  scsi: ufs: Allow reading descriptor via raw upiu
  scsi: ufs-bsg: Change the calling convention for write descriptor
  scsi: clean obsolete return values of eh_timed_out

Bart Van Assche (27):
  scsi: core: Move resid from scsi_data_buffer to scsi_cmnd
  scsi: sd: Remove superfluous residual assignments
  scsi: uas: Use scsi_[gs]et_resid() where appropriate
  scsi: scsi_debug: Use scsi_[gs]et_resid() where appropriate
  scsi: libiscsi: Use scsi_[gs]et_resid() where appropriate
  scsi: scsi_debug: Fix a recently introduced regression
  scsi: target/iscsi: Simplify iscsit_handle_text_cmd()
  scsi: target/iscsi: Simplify iscsit_dump_data_payload()
  scsi: target/iscsi: Avoid iscsit_release_commands_from_conn() deadlock
  scsi: target/iscsi: Rename a function and a function pointer
  scsi: target/iscsi: Fix spelling of "unsolicited"
  scsi: target/iscsi: Convert comments about locking into runtime checks
  scsi: target/iscsi: Remove an incorrect comment
  scsi: RDMA/srpt: Fix a credit leak for aborted commands
  scsi: RDMA/srpt: Rework I/O context allocation
  scsi: RDMA/srpt: Fix handling of TMF submission failure
  scsi: RDMA/srpt: Fix handling of command / TMF submission failure
  scsi: target/core: Add target_send_busy()
  scsi: target/core: Inline transport_lun_remove_cmd()
  scsi: target/core: Simplify the LUN RESET implementation
  scsi: target/core: Remove several state tests from the TMF code
  scsi: target/core: Remove the write_pending_status() callback function
  scsi: sd: Protect against READ(6) or WRITE(6) with zero block transfer 
length
  scsi: libsas: Remove scsi_to_u32()
  scsi: core: Remove an atomic instruction from the hot path
  scsi: sd: Rename 'SCpnt' into 'cmd'
  scsi: sd: Remove a local variable

Benjamin Block (1):
  scsi: core: replace GFP_ATOMIC with GFP_KERNEL in scsi_scan.c

Bill Kuzeja (1):
  scsi: qla2xxx: Move debug messages before sending srb preventing panic

Chengguang Xu (1):
  scsi: ufs: fix a typo in comment

Ching Huang (15):
  scsi: arcmsr: Update driver version to v1.40.00.10-20190116
  scsi: arcmsr: Fix suspend/resume of ACB_ADAPTER_TYPE_B part 2
  scsi: arcmsr: Use dma_alloc_coherent to replace dma_zalloc_coherent
  scsi: arcmsr: Update driver version to v1.40.00.10-20181217
  scsi: arcmsr: Fix suspend/resume of ACB_ADAPTER_TYPE_B
  scsi: arcmsr: Separate 'set dma mask' as a function
  scsi: arcmsr: Add an option of set dma_mask_64 for ACB_ADAPTER_TYPE_A
  scsi: arcmsr: Update ACB_ADAPTER_TYPE_D for >4GB ccb addressing
  scsi: arcmsr: Update ACB_ADAPTER_TYPE_C for >4GB ccb addressing
  scsi: arcmsr: Update ACB_ADAPTER_TYPE_B for >4GB ccb addressing
  scsi: arcmsr: Update ACB_ADAPTER_TYPE_A for >4GB ccb addressing
  scsi: arcmsr: Update arcmsr_alloc_ccb_pool for ccb buffer address above 
4GB
  scsi: arcmsr: Merge arcmsr_alloc_io_queue to arcmsr_alloc_ccb_pool
  scsi: arcmsr: Rename arcmsr_free_mu to arcmsr_free_io_queue
  scsi: arcmsr: Rename acb 

Re: [PATCH] modpost: file2alias: define size of alias

[Masahiro Yamada]

Hi Darren,


On Thu, Mar 7, 2019 at 3:17 PM Darren Hart  wrote:
>
> On Wed, Mar 06, 2019 at 10:09:26PM -0800, Darren Hart wrote:
> > On Sat, Feb 23, 2019 at 08:57:50PM +0100, Mattias Jacobsson wrote:
> > > On 2019-02-20, Masahiro Yamada wrote:
> >
> > > > > > If you want all the patches to go through x86 platform-driver tree,
> > > > > > I am fine with that too.
> > > > >
> > > > > I don't mind either way, however I've asked the x86 platform-driver
> > > > > maintainers if they have a preference in this matter. You should have
> > > > > received that mail otherwise see [1].
> > > > >
> > > > > [1]: 
> > > > > https://lkml.kernel.org/r/082d3d38b7dde6050b6b3e518ada439eade65b2c.1550603967.git@mok.nu
> > > >
> > > >
> > > > I saw it.  The 2/8 uses ALIAS_SIZE.
> > > >
> > > > So, I think it will be better to include this one in your series.
> > > > If necessary, please feel free to add
> > > >
> > > > Acked-by: Masahiro Yamada 
> > > >
> > >
> > > Okey, will do. Thanks!
> >
> >
> > Agree, I'll pull it in.
>
> Masahiro, may I include your Acked-by on the 2/8 patch as well?


Sure.  Please go ahead.




> platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()
>
> --
> Darren Hart
> VMware Open Source Technology Center



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v4 0/8] platform/x86: wmi: add WMI support to

[Darren Hart]

On Tue, Feb 19, 2019 at 08:59:48PM +0100, Mattias Jacobsson wrote:
> The kernel provides the macro MODULE_DEVICE_TABLE() which can help
> driver authors to generate the appropriate MODULE_ALIAS() output. The
> WMI device type is currently not supported by MODULE_DEVICE_TABLE().

Thanks Mattias. I have this queued up for testing, and with an ack from
Masahiro for 2/8, I'll pull this in. Thanks for the patches.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH linux-next v2 0/2] misc fix in src.c

[Kuninori Morimoto]

Hi Jiada

> two issues were found due to linux-next commit
> 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR handling")
> this patch-set address these two issues
> 
> ---
> v2: Update rsnd_of_match table instead of set priv->flags in probe
> 
> v1: initial version
> 
> Jiada Wang (2):
>   ASoC: rsnd: src: Avoid a potential deadlock
>   ASoC: rsnd: src: fix compiler warnings

Thank you for your patches.
For both patches

Acked-by: Kuninori Morimoto 

Re: [PATCH v9 02/11] powerpc: prepare string/mem functions for KASAN

[Christophe Leroy]

Hi Daniel,

On 03/04/2019 05:26 AM, Daniel Axtens wrote:

Hi Christophe,

diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
new file mode 100644
index ..c3161b8fc017
--- /dev/null
+++ b/arch/powerpc/include/asm/kasan.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifdef CONFIG_KASAN
+#define _GLOBAL_KASAN(fn)  .weak fn ; _GLOBAL(__##fn) ; _GLOBAL(fn)
+#define _GLOBAL_TOC_KASAN(fn)  .weak fn ; _GLOBAL_TOC(__##fn) ; _GLOBAL_TOC(fn)
+#define EXPORT_SYMBOL_KASAN(fn)EXPORT_SYMBOL(__##fn) ; 
EXPORT_SYMBOL(fn)


I'm having some trouble with this. I get warnings like this:

WARNING: EXPORT symbol "__memcpy" [vmlinux] version generation failed, symbol 
will not be versioned.


I don't have this problem, neither with my PPC32 defconfigs nor with 
ppc64e_defconfig - SPARSEMEM_VMEMMAP + KASAN

Using GCC 8.1

I've been looking into it in more details and can't understand the need 
for a weak symbol. A weak symbol is to allow it's optional replacement 
by other code. But here KASAN replaces it inconditionally, so I see no 
point for a weak symbol here.


Regarding the export of the functions, I believe that when the functions 
are defined in KASAN, they should be exported by KASAN and not by the 
arch. But such a change is out of scope for now. So lets have a double 
export for now, one day we will drop it.


Regarding export of __memcpy() etc..., there is at least the LKDTM 
module which inhibits KASAN, so it really needs to be exported.


What about the patch below ?

Christophe

diff --git a/arch/powerpc/include/asm/kasan.h 
b/arch/powerpc/include/asm/kasan.h

new file mode 100644
index ..2c179a39d4ba
--- /dev/null
+++ b/arch/powerpc/include/asm/kasan.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_KASAN_H
+#define __ASM_KASAN_H
+
+#ifdef CONFIG_KASAN
+#define _GLOBAL_KASAN(fn)  _GLOBAL(__##fn)
+#define _GLOBAL_TOC_KASAN(fn)  _GLOBAL_TOC(__##fn)
+#define EXPORT_SYMBOL_KASAN(fn)EXPORT_SYMBOL(__##fn)
+#else
+#define _GLOBAL_KASAN(fn)  _GLOBAL(fn)
+#define _GLOBAL_TOC_KASAN(fn)  _GLOBAL_TOC(fn)
+#define EXPORT_SYMBOL_KASAN(fn)
+#endif
+
+#endif
diff --git a/arch/powerpc/include/asm/string.h 
b/arch/powerpc/include/asm/string.h

index 1647de15a31e..9bf6dffb4090 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -4,14 +4,17 @@

 #ifdef __KERNEL__

+#ifndef CONFIG_KASAN
 #define __HAVE_ARCH_STRNCPY
 #define __HAVE_ARCH_STRNCMP
+#define __HAVE_ARCH_MEMCHR
+#define __HAVE_ARCH_MEMCMP
+#define __HAVE_ARCH_MEMSET16
+#endif
+
 #define __HAVE_ARCH_MEMSET
 #define __HAVE_ARCH_MEMCPY
 #define __HAVE_ARCH_MEMMOVE
-#define __HAVE_ARCH_MEMCMP
-#define __HAVE_ARCH_MEMCHR
-#define __HAVE_ARCH_MEMSET16
 #define __HAVE_ARCH_MEMCPY_FLUSHCACHE

 extern char * strcpy(char *,const char *);
@@ -27,7 +30,27 @@ extern int memcmp(const void *,const void 
*,__kernel_size_t);

 extern void * memchr(const void *,int,__kernel_size_t);
 extern void * memcpy_flushcache(void *,const void *,__kernel_size_t);

+void *__memset(void *s, int c, __kernel_size_t count);
+void *__memcpy(void *to, const void *from, __kernel_size_t n);
+void *__memmove(void *to, const void *from, __kernel_size_t n);
+
+#if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
+/*
+ * For files that are not instrumented (e.g. mm/slub.c) we
+ * should use not instrumented version of mem* functions.
+ */
+#define memcpy(dst, src, len) __memcpy(dst, src, len)
+#define memmove(dst, src, len) __memmove(dst, src, len)
+#define memset(s, c, n) __memset(s, c, n)
+
+#ifndef __NO_FORTIFY
+#define __NO_FORTIFY /* FORTIFY_SOURCE uses __builtin_memcpy, etc. */
+#endif
+
+#endif
+
 #ifdef CONFIG_PPC64
+#ifndef CONFIG_KASAN
 #define __HAVE_ARCH_MEMSET32
 #define __HAVE_ARCH_MEMSET64

@@ -49,8 +72,11 @@ static inline void *memset64(uint64_t *p, uint64_t v, 
__kernel_size_t n)

 {
return __memset64(p, v, n * 8);
 }
+#endif
 #else
+#ifndef CONFIG_KASAN
 #define __HAVE_ARCH_STRLEN
+#endif

 extern void *memset16(uint16_t *, uint16_t, __kernel_size_t);
 #endif
diff --git a/arch/powerpc/kernel/prom_init_check.sh 
b/arch/powerpc/kernel/prom_init_check.sh

index 667df97d2595..181fd10008ef 100644
--- a/arch/powerpc/kernel/prom_init_check.sh
+++ b/arch/powerpc/kernel/prom_init_check.sh
@@ -16,8 +16,16 @@
 # If you really need to reference something from prom_init.o add
 # it to the list below:

+grep "^CONFIG_KASAN=y$" .config >/dev/null
+if [ $? -eq 0 ]
+then
+   MEM_FUNCS="__memcpy __memset"
+else
+   MEM_FUNCS="memcpy memset"
+fi
+
 WHITELIST="add_reloc_offset __bss_start __bss_stop copy_and_flush
-_end enter_prom memcpy memset reloc_offset __secondary_hold
+_end enter_prom $MEM_FUNCS reloc_offset __secondary_hold
 __secondary_hold_acknowledge __secondary_hold_spinloop __start
 strcmp strcpy strlcpy strlen strncmp strstr kstrtobool logo_linux_clut224
 reloc_got2 kernstart_addr 

Re: [PATCH] modpost: file2alias: define size of alias

[Darren Hart]

On Wed, Mar 06, 2019 at 10:09:26PM -0800, Darren Hart wrote:
> On Sat, Feb 23, 2019 at 08:57:50PM +0100, Mattias Jacobsson wrote:
> > On 2019-02-20, Masahiro Yamada wrote:
> 
> > > > > If you want all the patches to go through x86 platform-driver tree,
> > > > > I am fine with that too.
> > > >
> > > > I don't mind either way, however I've asked the x86 platform-driver
> > > > maintainers if they have a preference in this matter. You should have
> > > > received that mail otherwise see [1].
> > > >
> > > > [1]: 
> > > > https://lkml.kernel.org/r/082d3d38b7dde6050b6b3e518ada439eade65b2c.1550603967.git@mok.nu
> > > 
> > > 
> > > I saw it.  The 2/8 uses ALIAS_SIZE.
> > > 
> > > So, I think it will be better to include this one in your series.
> > > If necessary, please feel free to add
> > > 
> > > Acked-by: Masahiro Yamada 
> > > 
> > 
> > Okey, will do. Thanks!
> 
> 
> Agree, I'll pull it in.

Masahiro, may I include your Acked-by on the 2/8 patch as well?

platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH linux-next v2 0/2] misc fix in src.c

[Jiada Wang]

two issues were found due to linux-next commit
7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR handling")
this patch-set address these two issues

---
v2: Update rsnd_of_match table instead of set priv->flags in probe

v1: initial version

Jiada Wang (2):
  ASoC: rsnd: src: Avoid a potential deadlock
  ASoC: rsnd: src: fix compiler warnings

 sound/soc/sh/rcar/core.c |  3 +++
 sound/soc/sh/rcar/rsnd.h |  5 +
 sound/soc/sh/rcar/src.c  | 21 +++--
 3 files changed, 15 insertions(+), 14 deletions(-)

-- 
2.19.2

[PATCH linux-next v2 2/2] ASoC: rsnd: src: fix compiler warnings

[Jiada Wang]

compiler complains about following declarations

sound/soc/sh/rcar/src.c:174:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsdsr_table_pattern1[] = {
 ^
sound/soc/sh/rcar/src.c:183:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsdsr_table_pattern2[] = {
 ^
sound/soc/sh/rcar/src.c:192:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsisr_table[] = {
 ^
sound/soc/sh/rcar/src.c:201:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan28[] = {
 ^
sound/soc/sh/rcar/src.c:210:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan244888[] = {
 ^
sound/soc/sh/rcar/src.c:219:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan22[] = {
 ^

This patch moves the 'static' keyword to the front of the
declaration to fix the compiler warnings

Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
handling")
Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/src.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index 45096a66c074..585ffba0244b 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -134,7 +134,7 @@ unsigned int rsnd_src_get_rate(struct rsnd_priv *priv,
return rate;
 }
 
-const static u32 bsdsr_table_pattern1[] = {
+static const u32 bsdsr_table_pattern1[] = {
0x0180, /* 6 - 1/6 */
0x0100, /* 6 - 1/4 */
0x00c0, /* 6 - 1/3 */
@@ -143,7 +143,7 @@ const static u32 bsdsr_table_pattern1[] = {
0x0040, /* 6 - 1   */
 };
 
-const static u32 bsdsr_table_pattern2[] = {
+static const u32 bsdsr_table_pattern2[] = {
0x0240, /* 6 - 1/6 */
0x0180, /* 6 - 1/4 */
0x0120, /* 6 - 1/3 */
@@ -152,7 +152,7 @@ const static u32 bsdsr_table_pattern2[] = {
0x0060, /* 6 - 1   */
 };
 
-const static u32 bsisr_table[] = {
+static const u32 bsisr_table[] = {
0x00100060, /* 6 - 1/6 */
0x00100040, /* 6 - 1/4 */
0x00100030, /* 6 - 1/3 */
@@ -161,7 +161,7 @@ const static u32 bsisr_table[] = {
0x00100020, /* 6 - 1   */
 };
 
-const static u32 chan28[] = {
+static const u32 chan28[] = {
0x0006, /* 1 to 2 */
0x01fe, /* 1 to 8 */
0x01fe, /* 1 to 8 */
@@ -170,7 +170,7 @@ const static u32 chan28[] = {
0x01fe, /* 1 to 8 */
 };
 
-const static u32 chan244888[] = {
+static const u32 chan244888[] = {
0x0006, /* 1 to 2 */
0x001e, /* 1 to 4 */
0x001e, /* 1 to 4 */
@@ -179,7 +179,7 @@ const static u32 chan244888[] = {
0x01fe, /* 1 to 8 */
 };
 
-const static u32 chan22[] = {
+static const u32 chan22[] = {
0x0006, /* 1 to 2 */
0x0006, /* 1 to 2 */
0x0006, /* 1 to 2 */
-- 
2.19.2

[PATCH linux-next v2 1/2] ASoC: rsnd: src: Avoid a potential deadlock

[Jiada Wang]

lockdep warns us that priv->lock and k->k_lock can cause a
deadlock when after acquire of k->k_lock, process is interrupted
by src, while in another routine of src .init, k->k_lock is
acquired with priv->lock held.

This patch avoids a potential deadlock by not calling soc_device_match()
in SRC .init callback, instead it adds new soc fields in priv->flags to
differentiate SoCs.

Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
handling")
Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/core.c | 2 ++
 sound/soc/sh/rcar/rsnd.h | 5 +
 sound/soc/sh/rcar/src.c  | 9 +
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 022996d2db13..4fe83e611c01 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -110,6 +110,8 @@ static const struct of_device_id rsnd_of_match[] = {
{ .compatible = "renesas,rcar_sound-gen1", .data = (void *)RSND_GEN1 },
{ .compatible = "renesas,rcar_sound-gen2", .data = (void *)RSND_GEN2 },
{ .compatible = "renesas,rcar_sound-gen3", .data = (void *)RSND_GEN3 },
+   /* Special Handling */
+   { .compatible = "renesas,rcar_sound-r8a77990", .data = (void 
*)(RSND_GEN3 | RSND_SOC_E) },
{},
 };
 MODULE_DEVICE_TABLE(of, rsnd_of_match);
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 90625c57847b..0e6ef4e18400 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -607,6 +607,8 @@ struct rsnd_priv {
 #define RSND_GEN1  (1 << 0)
 #define RSND_GEN2  (2 << 0)
 #define RSND_GEN3  (3 << 0)
+#define RSND_SOC_MASK  (0xFF << 4)
+#define RSND_SOC_E (1 << 4) /* E1/E2/E3 */
 
/*
 * below value will be filled on rsnd_gen_probe()
@@ -679,6 +681,9 @@ struct rsnd_priv {
 #define rsnd_is_gen1(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN1)
 #define rsnd_is_gen2(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN2)
 #define rsnd_is_gen3(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN3)
+#define rsnd_is_e3(priv)   (((priv)->flags & \
+   (RSND_GEN_MASK | RSND_SOC_MASK)) == \
+   (RSND_GEN3 | RSND_SOC_E))
 
 #define rsnd_flags_has(p, f) ((p)->flags & (f))
 #define rsnd_flags_set(p, f) ((p)->flags |= (f))
diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index db81e066b92e..45096a66c074 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -14,7 +14,6 @@
  */
 
 #include "rsnd.h"
-#include 
 
 #define SRC_NAME "src"
 
@@ -189,18 +188,12 @@ const static u32 chan22[] = {
0x0006, /* 1 to 2 */
 };
 
-static const struct soc_device_attribute ov_soc[] = {
-   { .soc_id = "r8a77990" }, /* E3 */
-   { /* sentinel */ }
-};
-
 static void rsnd_src_set_convert_rate(struct rsnd_dai_stream *io,
  struct rsnd_mod *mod)
 {
struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
struct device *dev = rsnd_priv_to_dev(priv);
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
-   const struct soc_device_attribute *soc = soc_device_match(ov_soc);
int is_play = rsnd_io_is_play(io);
int use_src = 0;
u32 fin, fout;
@@ -307,7 +300,7 @@ static void rsnd_src_set_convert_rate(struct 
rsnd_dai_stream *io,
/*
 * E3 need to overwrite
 */
-   if (soc)
+   if (rsnd_is_e3(priv))
switch (rsnd_mod_id(mod)) {
case 0:
case 4:
-- 
2.19.2

Re: [PATCH] modpost: file2alias: define size of alias

[Darren Hart]

On Sat, Feb 23, 2019 at 08:57:50PM +0100, Mattias Jacobsson wrote:
> On 2019-02-20, Masahiro Yamada wrote:

> > > > If you want all the patches to go through x86 platform-driver tree,
> > > > I am fine with that too.
> > >
> > > I don't mind either way, however I've asked the x86 platform-driver
> > > maintainers if they have a preference in this matter. You should have
> > > received that mail otherwise see [1].
> > >
> > > [1]: 
> > > https://lkml.kernel.org/r/082d3d38b7dde6050b6b3e518ada439eade65b2c.1550603967.git@mok.nu
> > 
> > 
> > I saw it.  The 2/8 uses ALIAS_SIZE.
> > 
> > So, I think it will be better to include this one in your series.
> > If necessary, please feel free to add
> > 
> > Acked-by: Masahiro Yamada 
> > 
> 
> Okey, will do. Thanks!


Agree, I'll pull it in.


-- 
Darren Hart
VMware Open Source Technology Center

[PATCH for-4.20] staging: erofs: compressed_pages should not be accessed again after freed

[Gao Xiang]

commit af692e117cb8cd9d3d844d413095775abc1217f9 upstream.

This patch resolves the following page use-after-free issue,
z_erofs_vle_unzip:
...
for (i = 0; i < nr_pages; ++i) {
...
z_erofs_onlinepage_endio(page);  (1)
}

for (i = 0; i < clusterpages; ++i) {
page = compressed_pages[i];

if (page->mapping == mngda)  (2)
continue;
/* recycle all individual staging pages */
(void)z_erofs_gather_if_stagingpage(page_pool, page); (3)
WRITE_ONCE(compressed_pages[i], NULL);
}
...

After (1) is executed, page is freed and could be then reused, if
compressed_pages is scanned after that, it could fall info (2) or
(3) by mistake and that could finally be in a mess.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
---
 drivers/staging/erofs/unzip_vle.c | 38 ++-
 drivers/staging/erofs/unzip_vle.h |  3 +--
 drivers/staging/erofs/unzip_vle_lz4.c | 19 --
 3 files changed, 29 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 1c4b3e0343f5..7182769f546a 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -904,11 +904,10 @@ static int z_erofs_vle_unzip(struct super_block *sb,
if (llen > grp->llen)
llen = grp->llen;
 
-   err = z_erofs_vle_unzip_fast_percpu(compressed_pages,
-   clusterpages, pages, llen, work->pageofs,
-   z_erofs_onlinepage_endio);
+   err = z_erofs_vle_unzip_fast_percpu(compressed_pages, clusterpages,
+   pages, llen, work->pageofs);
if (err != -ENOTSUPP)
-   goto out_percpu;
+   goto out;
 
if (sparsemem_pages >= nr_pages)
goto skip_allocpage;
@@ -929,8 +928,25 @@ static int z_erofs_vle_unzip(struct super_block *sb,
erofs_vunmap(vout, nr_pages);
 
 out:
+   /* must handle all compressed pages before endding pages */
+   for (i = 0; i < clusterpages; ++i) {
+   page = compressed_pages[i];
+
+#ifdef EROFS_FS_HAS_MANAGED_CACHE
+   if (page->mapping == mngda)
+   continue;
+#endif
+   /* recycle all individual staging pages */
+   (void)z_erofs_gather_if_stagingpage(page_pool, page);
+
+   WRITE_ONCE(compressed_pages[i], NULL);
+   }
+
for (i = 0; i < nr_pages; ++i) {
page = pages[i];
+   if (!page)
+   continue;
+
DBG_BUGON(page->mapping == NULL);
 
/* recycle all individual staging pages */
@@ -943,20 +959,6 @@ static int z_erofs_vle_unzip(struct super_block *sb,
z_erofs_onlinepage_endio(page);
}
 
-out_percpu:
-   for (i = 0; i < clusterpages; ++i) {
-   page = compressed_pages[i];
-
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (page->mapping == mngda)
-   continue;
-#endif
-   /* recycle all individual staging pages */
-   (void)z_erofs_gather_if_stagingpage(page_pool, page);
-
-   WRITE_ONCE(compressed_pages[i], NULL);
-   }
-
if (pages == z_pagemap_global)
mutex_unlock(_pagemap_global_lock);
else if (unlikely(pages != pages_onstack))
diff --git a/drivers/staging/erofs/unzip_vle.h 
b/drivers/staging/erofs/unzip_vle.h
index 3316bc36965d..684ff06fc7bf 100644
--- a/drivers/staging/erofs/unzip_vle.h
+++ b/drivers/staging/erofs/unzip_vle.h
@@ -218,8 +218,7 @@ extern int z_erofs_vle_plain_copy(struct page 
**compressed_pages,
 
 extern int z_erofs_vle_unzip_fast_percpu(struct page **compressed_pages,
unsigned clusterpages, struct page **pages,
-   unsigned outlen, unsigned short pageofs,
-   void (*endio)(struct page *));
+   unsigned int outlen, unsigned short pageofs);
 
 extern int z_erofs_vle_unzip_vmap(struct page **compressed_pages,
unsigned clusterpages, void *vaddr, unsigned llen,
diff --git a/drivers/staging/erofs/unzip_vle_lz4.c 
b/drivers/staging/erofs/unzip_vle_lz4.c
index 16ac335ee59f..8fa8a71a5445 100644
--- a/drivers/staging/erofs/unzip_vle_lz4.c
+++ b/drivers/staging/erofs/unzip_vle_lz4.c
@@ -105,8 +105,7 @@ int z_erofs_vle_unzip_fast_percpu(struct page 
**compressed_pages,
  unsigned int clusterpages,
  struct page **pages,
  unsigned int outlen,
- unsigned short pageofs,
- void (*endio)(struct page *))
+ unsigned short pageofs)
 {
   

Re: [PATCH v4] x86/gart/kcore: Exclude GART aperture from kcore

[Kairui Song]

On Thu, Mar 7, 2019 at 1:03 AM Jiri Bohac  wrote:
>
> Hi,
>
> On Wed, Mar 06, 2019 at 07:38:59PM +0800, Kairui Song wrote:
> > +int register_mem_pfn_is_ram(int (*fn)(unsigned long pfn))
> > +{
> > + if (mem_pfn_is_ram)
> > + return -EBUSY;
> > + mem_pfn_is_ram = fn;
> > + return 0;
> > +}
> > +
> > +void unregister_mem_pfn_is_ram(void)
> > +{
> > + mem_pfn_is_ram = NULL;
> > +}
> > +
> > +static int pfn_is_ram(unsigned long pfn)
> > +{
> > + if (mem_pfn_is_ram)
> > + return mem_pfn_is_ram(pfn);
> > + else
> > + return 1;
> > +}
> > +
>
> If anyone were ever to use unregister_mem_pfn_is_ram(),
> pfn_is_ram() would become racy.
>
> In V2 you had this:
> +   fn = mem_pfn_is_ram;
> +   if (fn)
> +   ret = fn(pfn);
>
> I agree it's unnecessary since nothing uses
> unregister_mem_pfn_is_ram(). But then I think it would be best to
> just drop the unregister function.
>
> Otherwise the patch looks good to me.
>

Good catch, let me remove the unregister function.
Also, I'd like to have an __init prefix for register_mem_pfn_is_ram,
will update in V5.

--
Best Regards,
Kairui Song

[PATCH] MAINTAINERS: Include mlxreg.h in Mellanox Platform Driver files

[Darren Hart (VMware)]

Avoid conflicts from other subsystems by including the header with the
rest of the driver files.

Cc: Andy Shevchenko 
Cc: Vadim Pasternak 
Signed-off-by: Darren Hart (VMware) 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 51029a425dbe..eb0b9aba4802 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9711,6 +9711,7 @@ M:Vadim Pasternak 
 L: platform-driver-...@vger.kernel.org
 S: Supported
 F: drivers/platform/mellanox/
+F: include/linux/platform_data/mlxreg.h
 
 MELLANOX MLX4 core VPI driver
 M: Tariq Toukan 
-- 
2.17.2


-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

[Jiri Kosina]

On Thu, 7 Mar 2019, Dominique Martinet wrote:

> > > 
> > >   addr = 4095
> > >   vma->vm_end = 4096
> > >   pages = 1000
> > > 
> > > then `end' is 4096 and `(end - addr) << PAGE_SHIFT' is zero, but it
> > > should have been 1.
> > 
> > Good catch! It should rather be something like
> > 
> > unsigned long pages = (end >> PAGE_SHIFT) - (addr >> PAGE_SHIFT);
> 
> That would be 0 for addr = 0 and vma->vm_end = 1; I assume we would
> still want to count that as one page.

Yeah, that was bogus as well, ETOOTIRED yesterday, sorry for the noise. 
Both the variants are off.

> I'm not too familiar with this area of the code, but I think there's a
> handy macro we can use for this, perhaps
>   DIV_ROUND_UP(end - addr, PAGE_SIZE) ?
> 
> kernel/kexec_core.c has defined PAGE_COUNT() which seems more
> appropriate but I do not see a global equivalent
> #define PAGE_COUNT(x) (((x) + PAGE_SIZE - 1) >> PAGE_SHIFT)

I'll fix that up when doing the other changes requested by Andrew.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] habanalabs: use %px instead of %p in error print

[Oded Gabbay]

On Thu, Mar 7, 2019 at 5:46 AM Kees Cook  wrote:
>
> On Sat, Mar 2, 2019 at 1:43 AM Oded Gabbay  wrote:
> >
> > When parsing the address of an internal command buffer, the driver prints
> > an error if the buffer's address is not in the range of the device's DRAM
> > or SRAM memory address space.
> >
> > Use %px to print the real address that the user gave the driver and not a
> > hashed value, so the user will get a clue regarding the origin of his
> > error.
> >
> > Note that if the print occurs, the pointer that is printed is a
> > user's virtual address and not some kind of physical address.
>
> Err, which virtual address space is this? If this is mapped into the
> kernel's virtual address space, this should not be %px...
No, it's not mapped to kernel in any way.
It's supposed to be an address in the device's address space.
As this is an error message, it's either a wrong address in the
device's address space, or it's a user-space virtual address.
Oded


>
> -Kees
>
> >
> > Suggested-by: Joe Perches 
> > Signed-off-by: Oded Gabbay 
> > ---
> >  drivers/misc/habanalabs/goya/goya.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/misc/habanalabs/goya/goya.c 
> > b/drivers/misc/habanalabs/goya/goya.c
> > index c4f3ec1e9d8b..238dd57c541b 100644
> > --- a/drivers/misc/habanalabs/goya/goya.c
> > +++ b/drivers/misc/habanalabs/goya/goya.c
> > @@ -4293,7 +4293,7 @@ static int goya_parse_cb_no_ext_quque(struct 
> > hl_device *hdev,
> > return 0;
> >
> > dev_err(hdev->dev,
> > -   "Internal CB address %p + 0x%x is not in SRAM nor 
> > in DRAM\n",
> > +   "Internal CB address %px + 0x%x is not in SRAM nor 
> > in DRAM\n",
> > parser->user_cb, parser->user_cb_size);
> >
> > return -EFAULT;
> > --
> > 2.18.0
> >
>
>
> --
> Kees Cook

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Wed, Mar 06, 2019 at 09:27:01PM -0800, Darren Hart wrote:
> On Mon, Mar 04, 2019 at 02:37:35PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the drivers-x86 tree got a conflict in:
> > 
> >   include/linux/platform_data/mlxreg.h
> > 
> > between commit:
> > 
> >   9f03161a1bd8 ("platform_data/mlxreg: additions for Mellanox watchdog 
> > driver.")
> > 
> > from the watchdog tree and commit:
> > 
> >   9b28aa1d0eae ("platform_data/mlxreg: Document fixes for core platform 
> > data")
> > 
> > from the drivers-x86 tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> 
> Thanks Stephen.
> 
> I suspect this will be a rare occurence. That said - Vadim - could you please
> ensure that all the mellanox driver changes Cc the platform driver x86 mailing
> list by adding it to MAINTAINERS?

And, turns out, not so rare. We've been down this road before. I'll just prepare
the patch for the MAINTAINERS.

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH for-4.19] staging: erofs: compressed_pages should not be accessed again after freed

[Gao Xiang]

commit af692e117cb8cd9d3d844d413095775abc1217f9 upstream.

This patch resolves the following page use-after-free issue,
z_erofs_vle_unzip:
...
for (i = 0; i < nr_pages; ++i) {
...
z_erofs_onlinepage_endio(page);  (1)
}

for (i = 0; i < clusterpages; ++i) {
page = compressed_pages[i];

if (page->mapping == mngda)  (2)
continue;
/* recycle all individual staging pages */
(void)z_erofs_gather_if_stagingpage(page_pool, page); (3)
WRITE_ONCE(compressed_pages[i], NULL);
}
...

After (1) is executed, page is freed and could be then reused, if
compressed_pages is scanned after that, it could fall info (2) or
(3) by mistake and that could finally be in a mess.

This patch aims to solve the above issue only with little changes
as much as possible in order to make the fix backport easier.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
---
 drivers/staging/erofs/unzip_vle.c | 38 ++-
 drivers/staging/erofs/unzip_vle.h |  3 +--
 drivers/staging/erofs/unzip_vle_lz4.c | 20 +-
 3 files changed, 30 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 1279241449f4..96fb93e86485 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -901,11 +901,10 @@ static int z_erofs_vle_unzip(struct super_block *sb,
if (llen > grp->llen)
llen = grp->llen;
 
-   err = z_erofs_vle_unzip_fast_percpu(compressed_pages,
-   clusterpages, pages, llen, work->pageofs,
-   z_erofs_onlinepage_endio);
+   err = z_erofs_vle_unzip_fast_percpu(compressed_pages, clusterpages,
+   pages, llen, work->pageofs);
if (err != -ENOTSUPP)
-   goto out_percpu;
+   goto out;
 
if (sparsemem_pages >= nr_pages)
goto skip_allocpage;
@@ -926,8 +925,25 @@ static int z_erofs_vle_unzip(struct super_block *sb,
erofs_vunmap(vout, nr_pages);
 
 out:
+   /* must handle all compressed pages before endding pages */
+   for (i = 0; i < clusterpages; ++i) {
+   page = compressed_pages[i];
+
+#ifdef EROFS_FS_HAS_MANAGED_CACHE
+   if (page->mapping == mngda)
+   continue;
+#endif
+   /* recycle all individual staging pages */
+   (void)z_erofs_gather_if_stagingpage(page_pool, page);
+
+   WRITE_ONCE(compressed_pages[i], NULL);
+   }
+
for (i = 0; i < nr_pages; ++i) {
page = pages[i];
+   if (!page)
+   continue;
+
DBG_BUGON(page->mapping == NULL);
 
/* recycle all individual staging pages */
@@ -940,20 +956,6 @@ static int z_erofs_vle_unzip(struct super_block *sb,
z_erofs_onlinepage_endio(page);
}
 
-out_percpu:
-   for (i = 0; i < clusterpages; ++i) {
-   page = compressed_pages[i];
-
-#ifdef EROFS_FS_HAS_MANAGED_CACHE
-   if (page->mapping == mngda)
-   continue;
-#endif
-   /* recycle all individual staging pages */
-   (void)z_erofs_gather_if_stagingpage(page_pool, page);
-
-   WRITE_ONCE(compressed_pages[i], NULL);
-   }
-
if (pages == z_pagemap_global)
mutex_unlock(_pagemap_global_lock);
else if (unlikely(pages != pages_onstack))
diff --git a/drivers/staging/erofs/unzip_vle.h 
b/drivers/staging/erofs/unzip_vle.h
index 3316bc36965d..684ff06fc7bf 100644
--- a/drivers/staging/erofs/unzip_vle.h
+++ b/drivers/staging/erofs/unzip_vle.h
@@ -218,8 +218,7 @@ extern int z_erofs_vle_plain_copy(struct page 
**compressed_pages,
 
 extern int z_erofs_vle_unzip_fast_percpu(struct page **compressed_pages,
unsigned clusterpages, struct page **pages,
-   unsigned outlen, unsigned short pageofs,
-   void (*endio)(struct page *));
+   unsigned int outlen, unsigned short pageofs);
 
 extern int z_erofs_vle_unzip_vmap(struct page **compressed_pages,
unsigned clusterpages, void *vaddr, unsigned llen,
diff --git a/drivers/staging/erofs/unzip_vle_lz4.c 
b/drivers/staging/erofs/unzip_vle_lz4.c
index 9cb35cd33365..055420e8af2c 100644
--- a/drivers/staging/erofs/unzip_vle_lz4.c
+++ b/drivers/staging/erofs/unzip_vle_lz4.c
@@ -105,8 +105,7 @@ int z_erofs_vle_unzip_fast_percpu(struct page 
**compressed_pages,
  unsigned clusterpages,
  struct page **pages,
  unsigned outlen,
- unsigned short pageofs,
- void (*endio)(struct page *))
+ unsigned short pageofs)
 {
void 

RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver

[Pawel Laszczak]

Hi,

>Pawel,
>
>On 14/02/2019 21:45, Pawel Laszczak wrote:
>> This patch introduce new Cadence USBSS DRD driver to linux kernel.
>>
>> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi
>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
>> Host Only (XHCI)configurations.
>>
>> The current driver has been validated with FPGA burned. We have support
>> for PCIe bus, which is used on FPGA prototyping.
>>
>> The host side of USBSS-DRD controller is compliance with XHCI
>> specification, so it works with standard XHCI linux driver.
>>
>> Signed-off-by: Pawel Laszczak 
>> ---
>>  drivers/usb/Kconfig|2 +
>>  drivers/usb/Makefile   |2 +
>>  drivers/usb/cdns3/Kconfig  |   44 +
>>  drivers/usb/cdns3/Makefile |   14 +
>>  drivers/usb/cdns3/cdns3-pci-wrap.c |  155 +++
>>  drivers/usb/cdns3/core.c   |  403 ++
>>  drivers/usb/cdns3/core.h   |  116 ++
>>  drivers/usb/cdns3/debug.h  |  168 +++
>>  drivers/usb/cdns3/debugfs.c|  164 +++
>>  drivers/usb/cdns3/drd.c|  365 +
>>  drivers/usb/cdns3/drd.h|  162 +++
>>  drivers/usb/cdns3/ep0.c|  907 +
>>  drivers/usb/cdns3/gadget-export.h  |   28 +
>>  drivers/usb/cdns3/gadget.c | 2003 
>>  drivers/usb/cdns3/gadget.h | 1207 +
>>  drivers/usb/cdns3/host-export.h|   28 +
>>  drivers/usb/cdns3/host.c   |   72 +
>>  drivers/usb/cdns3/trace.c  |   23 +
>>  drivers/usb/cdns3/trace.h  |  404 ++
>>  19 files changed, 6267 insertions(+)
>>  create mode 100644 drivers/usb/cdns3/Kconfig
>>  create mode 100644 drivers/usb/cdns3/Makefile
>>  create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c
>>  create mode 100644 drivers/usb/cdns3/core.c
>>  create mode 100644 drivers/usb/cdns3/core.h
>>  create mode 100644 drivers/usb/cdns3/debug.h
>>  create mode 100644 drivers/usb/cdns3/debugfs.c
>>  create mode 100644 drivers/usb/cdns3/drd.c
>>  create mode 100644 drivers/usb/cdns3/drd.h
>>  create mode 100644 drivers/usb/cdns3/ep0.c
>>  create mode 100644 drivers/usb/cdns3/gadget-export.h
>>  create mode 100644 drivers/usb/cdns3/gadget.c
>>  create mode 100644 drivers/usb/cdns3/gadget.h
>>  create mode 100644 drivers/usb/cdns3/host-export.h
>>  create mode 100644 drivers/usb/cdns3/host.c
>>  create mode 100644 drivers/usb/cdns3/trace.c
>>  create mode 100644 drivers/usb/cdns3/trace.h
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 987fc5ba6321..5f9334019d04 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -112,6 +112,8 @@ source "drivers/usb/usbip/Kconfig"
>>
>>  endif
>>
>> +source "drivers/usb/cdns3/Kconfig"
>> +
>>  source "drivers/usb/mtu3/Kconfig"
>>
>>  source "drivers/usb/musb/Kconfig"
>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
>> index 7d1b8c82b208..ab125b966cac 100644
>> --- a/drivers/usb/Makefile
>> +++ b/drivers/usb/Makefile
>> @@ -12,6 +12,8 @@ obj-$(CONFIG_USB_DWC3) += dwc3/
>>  obj-$(CONFIG_USB_DWC2)  += dwc2/
>>  obj-$(CONFIG_USB_ISP1760)   += isp1760/
>>
>> +obj-$(CONFIG_USB_CDNS3) += cdns3/
>> +
>>  obj-$(CONFIG_USB_MON)   += mon/
>>  obj-$(CONFIG_USB_MTU3)  += mtu3/
>>
>> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
>> new file mode 100644
>> index ..27cb3d8dbe3d
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/Kconfig
>> @@ -0,0 +1,44 @@
>> +config USB_CDNS3
>> +tristate "Cadence USB3 Dual-Role Controller"
>> +depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
>> +help
>> +  Say Y here if your system has a cadence USB3 dual-role controller.
>> +  It supports: dual-role switch, Host-only, and Peripheral-only.
>> +
>> +  If you choose to build this driver is a dynamically linked
>> +  as module, the module will be called cdns3.ko.
>> +
>> +if USB_CDNS3
>> +
>> +config USB_CDNS3_GADGET
>> +bool "Cadence USB3 device controller"
>> +depends on USB_GADGET
>> +help
>> +  Say Y here to enable device controller functionality of the
>> +  cadence USBSS-DEV driver.
>
>"Cadence" ?
>
>> +
>> +  This controller supports FF, HS and SS mode. It doesn't support
>> +  LS and SSP mode.
>> +
>> +config USB_CDNS3_HOST
>> +bool "Cadence USB3 host controller"
>> +depends on USB_XHCI_HCD
>> +help
>> +  Say Y here to enable host controller functionality of the
>> +  cadence driver.
>> +
>> +  Host controller is compliant with XHCI so it will use
>> +  standard XHCI driver.
>> +
>> +config USB_CDNS3_PCI_WRAP
>> +tristate "Cadence USB3 support on PCIe-based platforms"
>> +depends on USB_PCI && ACPI
>> +default USB_CDNS3
>> +help
>> +  If you're using the USBSS Core IP with a PCIe, please say
>> +  'Y' or 'M' here.
>> +
>> +  

[PATCH for-4.19] staging: erofs: fix mis-acted TAIL merging behavior

[Gao Xiang]

commit a112152f6f3a2a88caa6f414d540bd49e406af60 upstream.

EROFS has an optimized path called TAIL merging, which is designed
to merge multiple reads and the corresponding decompressions into
one if these requests read continuous pages almost at the same time.

In general, it behaves as follows:
 
  ... |  TAIL  .  HEAD  |  PAGE  |  PAGE  |  TAIL. HEAD | ...
 _|_combined page A_|||_combined page B_|
1  ]  ->  [  2  ]  ->  [ 3
If the above three reads are requested in the order 1-2-3, it will
generate a large work chain rather than 3 individual work chains
to reduce scheduling overhead and boost up sequential read.

However, if Read 2 is processed slightly earlier than Read 1,
currently it still generates 2 individual work chains (chain 1, 2)
but it does in-place decompression for combined page A, moreover,
if chain 2 decompresses ahead of chain 1, it will be a race and
lead to corrupted decompressed page. This patch fixes it.

Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support")
Cc:  # 4.19+
Signed-off-by: Gao Xiang 
Reviewed-by: Chao Yu 
---
 drivers/staging/erofs/unzip_vle.c | 69 +--
 1 file changed, 44 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/erofs/unzip_vle.c 
b/drivers/staging/erofs/unzip_vle.c
index 1279241449f4..24bd1d6deb66 100644
--- a/drivers/staging/erofs/unzip_vle.c
+++ b/drivers/staging/erofs/unzip_vle.c
@@ -57,15 +57,30 @@ enum z_erofs_vle_work_role {
Z_EROFS_VLE_WORK_SECONDARY,
Z_EROFS_VLE_WORK_PRIMARY,
/*
-* The current work has at least been linked with the following
-* processed chained works, which means if the processing page
-* is the tail partial page of the work, the current work can
-* safely use the whole page, as illustrated below:
-* +--+---+
-* |  tail page   |  head page (of the previous work) |
-* +--+---+
-*   /\  which belongs to the current work
-* [  (*) this page can be used for the current work itself.  ]
+* The current work was the tail of an exist chain, and the previous
+* processed chained works are all decided to be hooked up to it.
+* A new chain should be created for the remaining unprocessed works,
+* therefore different from Z_EROFS_VLE_WORK_PRIMARY_FOLLOWED,
+* the next work cannot reuse the whole page in the following scenario:
+*  
+* |  tail (partial) page |   head (partial) page   |
+* |  (belongs to the next work)  |  (belongs to the current work)  |
+* |___PRIMARY_FOLLOWED___|PRIMARY_HOOKED___|
+*/
+   Z_EROFS_VLE_WORK_PRIMARY_HOOKED,
+   /*
+* The current work has been linked with the processed chained works,
+* and could be also linked with the potential remaining works, which
+* means if the processing page is the tail partial page of the work,
+* the current work can safely use the whole page (since the next work
+* is under control) for in-place decompression, as illustrated below:
+*  
+* |  tail (partial) page  |  head (partial) page   |
+* | (of the current work) | (of the previous work) |
+* |  PRIMARY_FOLLOWED or  ||
+* |_PRIMARY_HOOKED|PRIMARY_FOLLOWED|
+*
+* [  (*) the above page can be used for the current work itself.  ]
 */
Z_EROFS_VLE_WORK_PRIMARY_FOLLOWED,
Z_EROFS_VLE_WORK_MAX
@@ -234,10 +249,10 @@ static int z_erofs_vle_work_add_page(
return ret ? 0 : -EAGAIN;
 }
 
-static inline bool try_to_claim_workgroup(
-   struct z_erofs_vle_workgroup *grp,
-   z_erofs_vle_owned_workgrp_t *owned_head,
-   bool *hosted)
+static enum z_erofs_vle_work_role
+try_to_claim_workgroup(struct z_erofs_vle_workgroup *grp,
+  z_erofs_vle_owned_workgrp_t *owned_head,
+  bool *hosted)
 {
DBG_BUGON(*hosted == true);
 
@@ -251,6 +266,9 @@ static inline bool try_to_claim_workgroup(
 
*owned_head = grp;
*hosted = true;
+   /* lucky, I am the followee :) */
+   return Z_EROFS_VLE_WORK_PRIMARY_FOLLOWED;
+
} else if (grp->next == Z_EROFS_VLE_WORKGRP_TAIL) {
/*
 * type 2, link to the end of a existing open chain,
@@ -260,12 +278,11 @@ static inline bool try_to_claim_workgroup(
if (Z_EROFS_VLE_WORKGRP_TAIL != 

Re: linux-next: manual merge of the drivers-x86 tree with the watchdog tree

[Darren Hart]

On Mon, Mar 04, 2019 at 02:37:35PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
> 
>   include/linux/platform_data/mlxreg.h
> 
> between commit:
> 
>   9f03161a1bd8 ("platform_data/mlxreg: additions for Mellanox watchdog 
> driver.")
> 
> from the watchdog tree and commit:
> 
>   9b28aa1d0eae ("platform_data/mlxreg: Document fixes for core platform data")
> 
> from the drivers-x86 tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks Stephen.

I suspect this will be a rare occurence. That said - Vadim - could you please
ensure that all the mellanox driver changes Cc the platform driver x86 mailing
list by adding it to MAINTAINERS?

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH] bcache: add cond_resched() in __bch_cache_cmp()

[shile . zhang]

From: Shile Zhang 

Read /sys/fs/bcache//cacheN/priority_stats can take very long
time with huge cache after long run.

Signed-off-by: Shile Zhang 
---
 drivers/md/bcache/sysfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 557a8a3..028fea1 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -897,6 +897,7 @@ static void bch_cache_set_internal_release(struct kobject 
*k)
 
 static int __bch_cache_cmp(const void *l, const void *r)
 {
+   cond_resched();
return *((uint16_t *)r) - *((uint16_t *)l);
 }
 
-- 
1.8.3.1

Is it possible to reset graphics controller on reboot in a framebuffer driver?

[Tom Li]

Hi all.

As you may have noticed, recently I've been working on a reworked version
of sm712fb, and planned to convert it to a DRM/KMS driver. Besides using
it on embedded/non-x86 systems, I thought it would be a good idea to support
histrocial x86 laptops with this VGA chipset as well, so I've acquired a
machine for testing.

However, soon I found a nasty problem. The BIOS does not reset the chip
on boot! Like most graphics controller of that era, sm712 chipset has a
VGA compatible mode and a 2D framebuffer mode. The power-on default is
VGA. The BIOS writer just assumed this, and does nothing to reinitialize
it. If one uses the framebuffer driver under Linux, once the machine reboots,
the entire LCD panel becomes a piece of garbage.

AFAIK, the framebuffer driver would be running throughout the kernel's life-
cycle, is it really possible to workaround this issue by restoring on VGA
state upon reboot?

Thanks,
Tom Li

Re: [RFC PATCH v1 08/25] printk: add ring buffer and kthread

[Sergey Senozhatsky]

Hi John,

On (03/05/19 22:00), John Ogness wrote:
> Hi Sergey,
> 
[..]
> Console printing is a convenient feature to allow a kernel to
> communicate information to a user without any reliance on
> userspace. IMHO there are 2 categories of messages that the kernel will
> communicate. The first is informational (usb events, wireless and
> ethernet connectivity, filesystem events, etc.). Since this category of
> messages occurs during normal runtime, we should expect that it does not
> cause adverse effects to the rest of the system (such as latencies and
> non-deterministic behavior).
> 
> The second category is for emergency situations, where the kernel needs
> to report something unusual (panic, BUG, WARN, etc.). In some of these
> situations, it may be the last thing the kernel ever does. We should
> expect this category to focus on getting the message out as reliably as
> possible. Even if it means disturbing the system with large latencies.
> 
> _Both_ categories are important for the user, but their requirements are
> different:
> 
>informational: non-disturbing
>emergency: reliable

That's one way of looking at this. And it's reasonable.

Another way could be:
 - anything that passes the loglevel check (suppress_message_printing())
   is considered to be important

 - anything else is just "noise" which should be suppressed. This
   is what loglevel and suppress_message_printing() are for - to tell
   the kernel what we want and what we don't want to be on the consoles.

> But what if can't be implemented? vt console, for example? Yes, the vt
> console would be tricky. It doesn't even support the current
> bust_spinlocks/oops_in_progress. But since the emergency category has a
> clear requirement (reliability)

"Reliability" - yes; the existence of emergency messages - no.

  "to report something unusual (panic, BUG, WARN, etc.). In some of
   these situations, it may be the last thing the kernel ever does."

But so may be the "informational" message. For example, not all ARCHs
sport NMI to detect and warn about a lockup/deadlock somewhere in usb
or wifi. The "informational" can be the last thing the kernel has to
say.

> The current printk implementation will do a better job of getting the
> informational messages out, but at an enormous cost to all the tasks
> on the system (including the realtime tasks). I am proposing a printk
> implementation where the tasks are not affected by console printing
> floods.

In new printk design the tasks are still affected by printing floods.
Tasks have to line up and (busy) wait for each other, regardless of
contexts.

One of the late patch sets which I had (I never ever published it) was
a different kind of printk-kthread offloading. The idea was that whatever
should be printed (suppress_message_printing()) should be printed. We
obviously can't loop in console_unlock() for ever and there is only one
way to figure out if we can print out more messages, that's why printk
became RCU stall detector and watchdog aware; and printk would break
out and wake up printk_kthread if it sees that watchdog is about to get
angry on that particular CPU. printk_kthread would run with preemption
disabled and do the same thing: if it spent watchdog_threshold / 2
printing - breakout, enable local IRQ, cond_resched(). IOW watchdogs
determine how much time we can spend on printing.

[..]
> I want messages of the information category to cause no disturbance to
> the system. Give the kernel the freedom to communicate to users without
> destroying its own performance. This can only be achieved if the
> messages are printed from a _fully_ preemptible context.
[..]
> And I want messages of the emergency category to be as reliable as
> possible, regardless of the costs to the system. Give the kernel a
> clear mechanism to _reliably_ communicate critical information.
> Such messages should never appear on a correctly functioning system.

I don't really understand the role of loglevel anymore.

When I do ./a.out --loglevel=X  I have a clear understanding that
all messages which fall into [critical, X] range will be in the logs,
because I told that application that those messages are important to
me right now. And it used to be the same with the kernel loglevel.
But now the kernel will do its own thing:

  - what the kernel considers important will go into the logs
  - what the kernel doesn't consider important _maybe_ will end up
in the logs (preemptible printk kthread). And this is where
loglevel now. After the _maybe_ part.

If I'm not mistaken, Tetsuo reported that on a box under heavy OOM
pressure he saw preemptible printk dragging 5 minutes behind the
logbuf head. Preemptible printk is good for nothing. It's beyond
useless, it's something else.

-ss

Re: [RFC PATCH] ntp: Avoid undefined behaviour in second_overflow()

[Richard Cochran]

On Wed, Mar 06, 2019 at 02:37:21PM +0100, Arnd Bergmann wrote:
> 
> There is also y2070 (many RTCs), y2100 (some other RTCs, especially
> those that assume it's a leap year), and y2106.

That's okay, Arnd.  When the time comes you can come out of retirement
and cash in, doing Y2.07, Y2.1, and Y2.106K consulting  ;^}

Cheers,
Richard

Re: [PATCH 2/2] Bluetooth: hci_qca: wcn3990: Drop baudrate change vendor event

[Balakrishna Godavarthi]

hi Matthias,

On 2019-03-07 06:10, Matthias Kaehlcke wrote:

Firmware download to the WCN3990 often fails with a 'TLV response size
mismatch' error:

[  133.064659] Bluetooth: hci0: setting up wcn3990
[  133.489150] Bluetooth: hci0: QCA controller version 0x02140201
[  133.495245] Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
[  133.507214] Bluetooth: hci0: QCA TLV response size mismatch
[  133.513265] Bluetooth: hci0: QCA Failed to download patch (-84)

This is caused by a vendor event that corresponds to an earlier command
to change the baudrate. The event is not processed in the context of 
the

baudrate change and later interpreted as response to the firmware
download command (which is also a vendor command), but the driver 
detects

that the event doesn't have the expected amount of associated data.

More details:

For the WCN3990 the vendor command for a baudrate change isn't sent as
synchronous HCI command, because the controller sends the corresponding
vendor event with the new baudrate. The event is received and decoded
after the baudrate change of the host port.

Identify the 'unused' event when it is received and don't add it to
the queue of RX frames.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/bluetooth/hci_qca.c | 54 ++---
 1 file changed, 51 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index ab8e59419dbc4..565681a6a1167 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -30,6 +30,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,6 +56,7 @@
 #define HCI_MAX_IBS_SIZE   10

 #define QCA_IN_BAND_SLEEP_ENABLED  BIT(0)
+#define QCA_DROP_VENDOR_EVENT  BIT(1)

 #define IBS_WAKE_RETRANS_TIMEOUT_MS100
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
@@ -108,6 +110,7 @@ struct qca_data {
struct work_struct ws_rx_vote_off;
struct work_struct ws_tx_vote_off;
unsigned long flags;
+   struct completion drop_ev_comp;

/* For debugging purpose */
u64 ibs_sent_wacks;
@@ -474,6 +477,7 @@ static int qca_open(struct hci_uart *hu)
INIT_WORK(>ws_tx_vote_off, qca_wq_serial_tx_clock_vote_off);

qca->hu = hu;
+   init_completion(>drop_ev_comp);

/* Assume we start with both sides asleep -- extra wakes OK */
qca->tx_ibs_state = HCI_IBS_TX_ASLEEP;
@@ -866,6 +870,33 @@ static int qca_recv_acl_data(struct hci_dev
*hdev, struct sk_buff *skb)
return hci_recv_frame(hdev, skb);
 }

+static int qca_recv_event(struct hci_dev *hdev, struct sk_buff *skb)
+{
+   struct hci_uart *hu = hci_get_drvdata(hdev);
+   struct qca_data *qca = hu->priv;
+
+   if (test_bit(QCA_DROP_VENDOR_EVENT, >flags)) {
+   struct hci_event_hdr *hdr = (void *)skb->data;
+
+   /* For the WCN3990 the vendor command for a baudrate change
+* isn't sent as synchronous HCI command, because the
+* controller sends the corresponding vendor event with the
+* new baudrate. The event is received and properly decoded
+* after changing the baudrate of the host port. It needs to
+* be dropped, otherwise it can be mis-interpreted as
+* response to a later firmware download command (also a
+* vendor command).
+*/
+
+   if (hdr->evt == HCI_EV_VENDOR)
+   complete(>drop_ev_comp);
+
+   return 0;
+   }
+
+   return hci_recv_frame(hdev, skb);
+}
+
 #define QCA_IBS_SLEEP_IND_EVENT \
.type = HCI_IBS_SLEEP_IND, \
.hlen = 0, \
@@ -890,7 +921,7 @@ static int qca_recv_acl_data(struct hci_dev *hdev,
struct sk_buff *skb)
 static const struct h4_recv_pkt qca_recv_pkts[] = {
{ H4_RECV_ACL, .recv = qca_recv_acl_data },
{ H4_RECV_SCO, .recv = hci_recv_frame},
-   { H4_RECV_EVENT,   .recv = hci_recv_frame},
+   { H4_RECV_EVENT,   .recv = qca_recv_event},
{ QCA_IBS_WAKE_IND_EVENT,  .recv = qca_ibs_wake_ind  },
{ QCA_IBS_WAKE_ACK_EVENT,  .recv = qca_ibs_wake_ack  },
{ QCA_IBS_SLEEP_IND_EVENT, .recv = qca_ibs_sleep_ind },
@@ -1091,6 +1122,7 @@ static int qca_set_speed(struct hci_uart *hu,
enum qca_speed_type speed_type)
 {
unsigned int speed, qca_baudrate;
struct qca_serdev *qcadev;
+   struct qca_data *qca = hu->priv;
int ret = 0;

if (speed_type == QCA_INIT_SPEED) {
@@ -1106,8 +1138,11 @@ static int qca_set_speed(struct hci_uart *hu,
enum qca_speed_type speed_type)
 * changing the baudrate of chip and host.
 */
qcadev = serdev_device_get_drvdata(hu->serdev);
-   if (qcadev->btsoc_type == QCA_WCN3990)
+   if (qcadev->btsoc_type == QCA_WCN3990) {
hci_uart_set_flow_control(hu, 

Re: [PATCH v5 5/5] i2c: mediatek: Add i2c support for MediaTek MT8183

[Qii Wang]

On Wed, 2019-03-06 at 18:52 +0800, Nicolas Boichat wrote:
> On Tue, Feb 26, 2019 at 9:11 PM Qii Wang  wrote:
> >
> > Add i2c compatible for MT8183. Compare to MT2712 i2c controller,
> > MT8183 has different register offsets. Ltiming_reg is added to
> > adjust low width of SCL. Arb clock and dma_sync are needed.
> >
> > Signed-off-by: Qii Wang 
> > ---
> >  drivers/i2c/busses/i2c-mt65xx.c |   53 
> > +--
> >  1 file changed, 51 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c 
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index 75d88e1..82eedbd 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > @@ -133,6 +133,8 @@ enum I2C_REGS_OFFSET {
> > OFFSET_DEBUGCTRL,
> > OFFSET_TRANSFER_LEN_AUX,
> > OFFSET_CLOCK_DIV,
> > +   /* MT8183 only regs */
> > +   OFFSET_LTIMING,
> >  };
> >
> >  static const u16 mt_i2c_regs_v1[] = {
> > @@ -162,6 +164,32 @@ enum I2C_REGS_OFFSET {
> > [OFFSET_CLOCK_DIV] = 0x70,
> >  };
> >
> > +static const u16 mt_i2c_regs_v2[] = {
> > +   [OFFSET_DATA_PORT] = 0x0,
> > +   [OFFSET_SLAVE_ADDR] = 0x4,
> > +   [OFFSET_INTR_MASK] = 0x8,
> > +   [OFFSET_INTR_STAT] = 0xc,
> > +   [OFFSET_CONTROL] = 0x10,
> > +   [OFFSET_TRANSFER_LEN] = 0x14,
> > +   [OFFSET_TRANSAC_LEN] = 0x18,
> > +   [OFFSET_DELAY_LEN] = 0x1c,
> > +   [OFFSET_TIMING] = 0x20,
> > +   [OFFSET_START] = 0x24,
> > +   [OFFSET_EXT_CONF] = 0x28,
> > +   [OFFSET_LTIMING] = 0x2c,
> > +   [OFFSET_HS] = 0x30,
> > +   [OFFSET_IO_CONFIG] = 0x34,
> > +   [OFFSET_FIFO_ADDR_CLR] = 0x38,
> > +   [OFFSET_TRANSFER_LEN_AUX] = 0x44,
> > +   [OFFSET_CLOCK_DIV] = 0x48,
> > +   [OFFSET_SOFTRESET] = 0x50,
> > +   [OFFSET_DEBUGSTAT] = 0xe0,
> > +   [OFFSET_DEBUGCTRL] = 0xe8,
> > +   [OFFSET_FIFO_STAT] = 0xf4,
> > +   [OFFSET_FIFO_THRESH] = 0xf8,
> > +   [OFFSET_DCM_EN] = 0xf88,
> > +};
> > +
> >  struct mtk_i2c_compatible {
> > const struct i2c_adapter_quirks *quirks;
> > const u16 *regs;
> > @@ -195,6 +223,7 @@ struct mtk_i2c {
> > enum mtk_trans_op op;
> > u16 timing_reg;
> > u16 high_speed_reg;
> > +   u16 ltiming_reg;
> > unsigned char auto_restart;
> > bool ignore_restart_irq;
> > const struct mtk_i2c_compatible *dev_comp;
> > @@ -271,12 +300,24 @@ struct mtk_i2c {
> > .dma_sync = 0,
> >  };
> >
> > +static const struct mtk_i2c_compatible mt8183_compat = {
> > +   .regs = mt_i2c_regs_v2,
> > +   .pmic_i2c = 0,
> > +   .dcm = 0,
> > +   .auto_restart = 1,
> > +   .aux_len_reg = 1,
> > +   .support_33bits = 1,
> > +   .timing_adjust = 1,
> > +   .dma_sync = 1,
> > +};
> > +
> >  static const struct of_device_id mtk_i2c_of_match[] = {
> > { .compatible = "mediatek,mt2712-i2c", .data = _compat },
> > { .compatible = "mediatek,mt6577-i2c", .data = _compat },
> > { .compatible = "mediatek,mt6589-i2c", .data = _compat },
> > { .compatible = "mediatek,mt7622-i2c", .data = _compat },
> > { .compatible = "mediatek,mt8173-i2c", .data = _compat },
> > +   { .compatible = "mediatek,mt8183-i2c", .data = _compat },
> > {}
> >  };
> >  MODULE_DEVICE_TABLE(of, mtk_i2c_of_match);
> > @@ -361,6 +402,8 @@ static void mtk_i2c_init_hw(struct mtk_i2c *i2c)
> >
> > mtk_i2c_writew(i2c, i2c->timing_reg, OFFSET_TIMING);
> > mtk_i2c_writew(i2c, i2c->high_speed_reg, OFFSET_HS);
> > +   if (i2c->dev_comp->regs == mt_i2c_regs_v2)
> > +   mtk_i2c_writew(i2c, i2c->ltiming_reg, OFFSET_LTIMING);
> 
> Matthias wasn't super happy with this. One way is to add another field
> in the compatible string. Another may be to have
> mt_i2c_regs_v1[OFFSET_LTIMING] point at, say 0x (#define this as
> I2C_REG_INVALID or something), and test for that?
> 
> Either way would scale better if we end up with more than 2 versions
> of the register set in the future.
> 

ok, I will add a flag(ltiming_adjust) in mtk_i2c_compatible.

> > /* If use i2c pin from PMIC mt6397 side, need set PATH_DIR first */
> > if (i2c->have_pmic)
> > @@ -460,6 +503,8 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, 
> > unsigned int parent_clk)
> > unsigned int clk_src;
> > unsigned int step_cnt;
> > unsigned int sample_cnt;
> > +   unsigned int l_step_cnt;
> > +   unsigned int l_sample_cnt;
> > unsigned int target_speed;
> > int ret;
> >
> > @@ -469,11 +514,11 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, 
> > unsigned int parent_clk)
> > if (target_speed > MAX_FS_MODE_SPEED) {
> > /* Set master code speed register */
> > ret = mtk_i2c_calculate_speed(i2c, clk_src, 
> > MAX_FS_MODE_SPEED,
> > - _cnt, _cnt);
> > +   

Re: [PATCH v5 2/7] x86, olpc: Use a correct version when making up a battery node

[Darren Hart]

On Thu, Jan 10, 2019 at 06:40:00PM +0100, Lubomir Rintel wrote:
> The XO-1 and XO-1.5 batteries apparently differ in an ability to report
> ambient temperature. Add a different compatible string to the 1.5
> battery.

Hi Lubomir,

Thanks for the recent Cc and pointer to here. In general, I have no
problem with the net changes. I do have some concerns from a
reviewability and change documentation perspective.

You document your intent above, but you also made several other changes
to get there which aren't documented, so when reviewing they stand out
as "why is this here?".

>From what I can tell, this change contains:

1) Cleanup of olpc_dt_interpret() calls to avoid splitting string
literals (noted in the patch history, but not called out as an
intentional change)

2) Refactoring of logic and breaking out the check for the compatible
property into olpc_dt_compatible_match

3) Addition of "we're running very old firmware if this is missing"
checks - I'm not sure how this relates to the stated problem and
the intended fix.

4) The addition of the xo1.5 compatible property.

All the other things makes it very difficult to determine if this patch
does what you describe - and only what you describe.

In general please:
a) Cleanup code
b) Refactor code
c) Change functionality

In that order - that way the new functionality is what show up when
someone does a git blame on the file (rather than a cleanup patch, which
isn't as useful in defect analysis).

And always document in your commit messages the approach you take to fix
the reported issue.

Thanks,


-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel

[Masahiro Yamada]

On Thu, Mar 7, 2019 at 5:13 AM Joel Fernandes  wrote:
>
> Hi Masahiro,
> Thanks for review, my replies are inline:
>
> On Wed, Mar 06, 2019 at 09:26:14PM +0900, Masahiro Yamada wrote:
> > On Mon, Mar 4, 2019 at 1:15 AM Joel Fernandes  wrote:
> > >
> > > This report is for an older version of the patch so ignore it. The
> > > issue is already resolved.
> > >
> > > On Sat, Mar 2, 2019 at 2:00 PM kbuild test robot  wrote:
> > > >
> > > > Hi Joel,
> > > >
> > > > Thank you for the patch! Yet something to improve:
> > > >
> > > > [auto build test ERROR on linus/master]
> > > > [also build test ERROR on v5.0-rc8]
> > > > [cannot apply to next-20190301]
> > > > [if your patch is applied to the wrong git tree, please drop us a note 
> > > > to help improve the system]
> > > >
> > > > url:
> > > > https://github.com/0day-ci/linux/commits/Joel-Fernandes-Google/Provide-in-kernel-headers-for-making-it-easy-to-extend-the-kernel/20190303-014850
> > > > config: sh-allmodconfig (attached as .config)
> > > > compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> > > > reproduce:
> > > > wget 
> > > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
> > > >  -O ~/bin/make.cross
> > > > chmod +x ~/bin/make.cross
> > > > # save the attached .config to linux build tree
> > > > GCC_VERSION=8.2.0 make.cross ARCH=sh
> > > >
> > > > All errors (new ones prefixed by >>):
> > > >
> > > > >> find: 'arch/sh/kernel/module.lds': No such file or directory
> > > > >> find: 'arch/sh/kernel/module.lds': No such file or directory
> > > >
> > > > ---
> > > > 0-DAY kernel test infrastructureOpen Source Technology 
> > > > Center
> > > > https://lists.01.org/pipermail/kbuild-all   Intel 
> > > > Corporation
> > > >
> > > > --
> > > > You received this message because you are subscribed to the Google 
> > > > Groups "kernel-team" group.
> > > > To unsubscribe from this group and stop receiving emails from it, send 
> > > > an email to kernel-team+unsubscr...@android.com.
> >
> >
> >
> > Honestly speaking, I am worried about some flaws
> > in this feature, but anyway I read your code.
>
> I am not sure what you mean by that :-(. All the previous series's comments
> were addressed and it has been well tested by me and others. This looks quite
> solid to me. Sorry it took so many revisions, this was not that easy to get 
> right.
>
> > Here are just comments from the build system point of view
> > in case something might be useful.
> >
> > Please feel free to adopt some of them if you think they are good.
> >> [1]
> >
> > Please do not ignore kbuild test robot.
> >
> > It never makes such a mistake like
> > replying to a new patch about the test result from old version.
> >
> > The reports are really addressing this version (v4).
> >
> > I see the error message even on x86.
>
> I did not mean to. By the way - the error does not cause any issues. It is
> just find being noisy. You are right I missed this, and I will correct this
> in v5. However, it does not cause any issues to the feature/functionality at 
> all.
>
> > [2]
> >
> > The shell script keeps running
> > even when an error occurs.
> >
> > If any line in a shell script fails,
> > probably it went already wrong.
> >
> > I highly recommend to add 'set -e'
> > at the very beginning of your shell script.
> >
> > It will propagate the error to Make.
>
> Ok I will consider making it -e. But please note that, the script itself does
> not have any bugs.

Heh.
I do not know why you are so confident with your code, though.

OK, let's say this script has no bug.

But, the script may fail for a different reason.
For example, what if cpio is not installed on the user's machine.

In such a situation, this script will produce empty
kernel/kheaders_data.tar.xz, but the build system
will continue running, and succeed.

Don't you think it will better to let the build immediately fail
than letting the user debug a wrongly created image ?



> When you say it this way, it looks a bit bad to the
> onlooker as if there is bugs in the code, but there aren't any that I know
> off. All the comments in this round of review from view are just cosmetic
> changes.
>
> > [3]
> >
> > targets += kheaders_data.tar.xz
> > targets += kheaders_data.h
> > targets += kheaders.md5
> >
> > These three lines are unneeded because
> > 'targets' is necessary just for if_changed or if_changed_rule.
> >
> > Instead, please add
> >
> > clean-files := kheaders_data.tar.xz kheaders_data.h kheaders.md5
>
> Ok.
>
> > [4]
> >
> > It is pointless to pass 'ikh_file_list'
> > from Makefile to the shell script.
> >
> >
> > You can directly describe the following in gen_ikh_data.sh
> >
> > You do not need to use sed.
> >
> >
> > src_file_list="
> > include/
> > arch/$SRCARCH/Makefile
> > arch/$SRCARCH/include/
> > arch/$SRCARCH/kernel/module.lds
> > scripts/
> > Makefile
> > "
> >
> > obj_file_list="
> > scripts/
> > include/
> > arch/$SRCARCH/include/
> 

Re: [PATCH v5 3/5] i2c: mediatek: Add arb clock in i2c driver

[Qii Wang]

On Wed, 2019-03-06 at 18:49 +0800, Nicolas Boichat wrote:
> One thing I missed from Matthias' comment on v4:
> https://patchwork.kernel.org/patch/10822083/
> 
> On Wed, Mar 6, 2019 at 6:44 PM Nicolas Boichat  wrote:
> >
> > On Tue, Feb 26, 2019 at 9:11 PM Qii Wang  wrote:
> > >
> > > When two i2c controllers are internally connected to the same
> > > GPIO pins, the arb clock is needed to ensure that the waveforms
> > > do not interfere with each other.
> > >
> > > Signed-off-by: Qii Wang 
> >
> > Reviewed-by: Nicolas Boichat 
> >
> > > ---
> > >  drivers/i2c/busses/i2c-mt65xx.c |   25 ++---
> > >  1 file changed, 22 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-mt65xx.c 
> > > b/drivers/i2c/busses/i2c-mt65xx.c
> > > index 428ac99..14d6b38 100644
> > > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > > @@ -35,6 +35,7 @@
> > >  #include 
> > >
> > >  #define I2C_RS_TRANSFER(1 << 4)
> > > +#define I2C_ARB_LOST   (1 << 3)
> > >  #define I2C_HS_NACKERR (1 << 2)
> > >  #define I2C_ACKERR (1 << 1)
> > >  #define I2C_TRANSAC_COMP   (1 << 0)
> > > @@ -181,6 +182,7 @@ struct mtk_i2c {
> > > struct clk *clk_main;   /* main clock for i2c bus */
> > > struct clk *clk_dma;/* DMA clock for i2c via DMA */
> > > struct clk *clk_pmic;   /* PMIC clock for i2c from PMIC */
> > > +   struct clk *clk_arb;/* Arbitrator clock for i2c */
> > > bool have_pmic; /* can use i2c pins from PMIC */
> > > bool use_push_pull; /* IO config push-pull mode */
> > >
> > > @@ -299,8 +301,18 @@ static int mtk_i2c_clock_enable(struct mtk_i2c *i2c)
> > > if (ret)
> > > goto err_pmic;
> > > }
> > > +
> > > +   if (i2c->clk_arb) {
> > > +   ret = clk_prepare_enable(i2c->clk_arb);
> > > +   if (ret)
> > > +   goto err_arb;
> > > +   }
> > > +
> > > return 0;
> > >
> > > +err_arb:
> > > +   if (i2c->have_pmic)
> > > +   clk_disable_unprepare(i2c->clk_pmic);
> > >  err_pmic:
> > > clk_disable_unprepare(i2c->clk_main);
> > >  err_main:
> > > @@ -311,6 +323,9 @@ static int mtk_i2c_clock_enable(struct mtk_i2c *i2c)
> > >
> > >  static void mtk_i2c_clock_disable(struct mtk_i2c *i2c)
> > >  {
> > > +   if (i2c->clk_arb)
> > > +   clk_disable_unprepare(i2c->clk_arb);
> > > +
> > > if (i2c->have_pmic)
> > > clk_disable_unprepare(i2c->clk_pmic);
> > >
> > > @@ -519,13 +534,13 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> > > struct i2c_msg *msgs,
> > >
> > > /* Clear interrupt status */
> > > mtk_i2c_writew(i2c, restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
> > > -  I2C_TRANSAC_COMP, OFFSET_INTR_STAT);
> > > +   I2C_ARB_LOST | I2C_TRANSAC_COMP, 
> > > OFFSET_INTR_STAT);
> 
> Is it ok to set I2C_ARB_LOST on _all_ SoC that this driver supports?
> If so, please at least say so in the commit message.
> 

Yes, old and new SoC have the I2C_ARB_LOST bit, but there was no need
for multi-master before, so we didn't set it up specifically, I have
test the patch on the old SoCs. I will add a note in the commit message.

> > >
> > > mtk_i2c_writew(i2c, I2C_FIFO_ADDR_CLR, OFFSET_FIFO_ADDR_CLR);
> > >
> > > /* Enable interrupt */
> > > mtk_i2c_writew(i2c, restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
> > > -  I2C_TRANSAC_COMP, OFFSET_INTR_MASK);
> > > +   I2C_ARB_LOST | I2C_TRANSAC_COMP, 
> > > OFFSET_INTR_MASK);
> > >
> > > /* Set transfer and transaction len */
> > > if (i2c->op == I2C_MASTER_WRRD) {
> > > @@ -659,7 +674,7 @@ static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, 
> > > struct i2c_msg *msgs,
> > >
> > > /* Clear interrupt mask */
> > > mtk_i2c_writew(i2c, ~(restart_flag | I2C_HS_NACKERR | I2C_ACKERR |
> > > -  I2C_TRANSAC_COMP), OFFSET_INTR_MASK);
> > > +   I2C_ARB_LOST | I2C_TRANSAC_COMP), 
> > > OFFSET_INTR_MASK);
> > >
> > > if (i2c->op == I2C_MASTER_WR) {
> > > dma_unmap_single(i2c->dev, wpaddr,
> > > @@ -884,6 +899,10 @@ static int mtk_i2c_probe(struct platform_device 
> > > *pdev)
> > > return PTR_ERR(i2c->clk_dma);
> > > }
> > >
> > > +   i2c->clk_arb = devm_clk_get(>dev, "arb");
> > > +   if (IS_ERR(i2c->clk_arb))
> > > +   i2c->clk_arb = NULL;
> > > +
> > > clk = i2c->clk_main;
> > > if (i2c->have_pmic) {
> > > i2c->clk_pmic = devm_clk_get(>dev, "pmic");
> > > --
> > > 1.7.9.5
> > >

[PATCH 0/2] Make ipmr queue length configurable

[Brodie Greenfield]

We want to have some more space in our queue for processing incoming
multicast packets, so we can process more of them without dropping
them prematurely. It is useful to be able to increase this limit on
higher-spec platforms that can handle more items.

For the particular use case here at Allied Telesis, we have linux
running on our switches and routers, with support for the number of
multicast groups being increased. Basically, this queue length affects
the time taken to fully learn all of the multicast streams. 

Changes in v3:
 - Corrected a v4 to v6 typo.

Changes in v2:
 - Tidy up a few unnecessary bits of code.
 - Put the sysctl inside ip multicast ifdef.
 - Included the IPv6 version.

Brodie Greenfield (2):
  ipmr: Make cache queue length configurable
  ip6mr: Make cache queue length configurable

 Documentation/networking/ip-sysctl.txt | 16 
 include/net/netns/ipv4.h   |  1 +
 include/net/netns/ipv6.h   |  1 +
 net/ipv4/af_inet.c |  1 +
 net/ipv4/ipmr.c|  4 +++-
 net/ipv4/sysctl_net_ipv4.c |  7 +++
 net/ipv6/af_inet6.c|  1 +
 net/ipv6/ip6mr.c   |  4 +++-
 net/ipv6/sysctl_net_ipv6.c |  7 +++
 9 files changed, 40 insertions(+), 2 deletions(-)

-- 
2.21.0

[PATCH 1/2] ipmr: Make cache queue length configurable

[Brodie Greenfield]

We want to be able to keep more spaces available in our queue for
processing incoming multicast traffic (adding (S,G) entries) - this lets
us learn more groups faster, rather than dropping them at this stage.

Signed-off-by: Brodie Greenfield 
---
 Documentation/networking/ip-sysctl.txt | 8 
 include/net/netns/ipv4.h   | 1 +
 net/ipv4/af_inet.c | 1 +
 net/ipv4/ipmr.c| 4 +++-
 net/ipv4/sysctl_net_ipv4.c | 7 +++
 5 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index acdfb5d2bcaa..02f77e932adf 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -887,6 +887,14 @@ ip_local_reserved_ports - list of comma separated ranges
 
Default: Empty
 
+ip_mr_cache_queue_length - INTEGER
+   Limit the number of multicast packets we can have in the queue to be
+   resolved.
+   Bear in mind that when an unresolved multicast packet is received,
+   there is an O(n) traversal of the queue. This should be considered
+   if increasing.
+   Default: 10
+
 ip_unprivileged_port_start - INTEGER
This is a per-namespace sysctl.  It defines the first
unprivileged port in the network namespace.  Privileged ports
diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 104a6669e344..3411d3f18d51 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -187,6 +187,7 @@ struct netns_ipv4 {
int sysctl_igmp_max_msf;
int sysctl_igmp_llm_reports;
int sysctl_igmp_qrv;
+   unsigned int sysctl_ip_mr_cache_queue_length;
 
struct ping_group_range ping_group_range;
 
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index 0dfb72c46671..8e25538bdb1e 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1827,6 +1827,7 @@ static __net_init int inet_init_net(struct net *net)
net->ipv4.sysctl_igmp_llm_reports = 1;
net->ipv4.sysctl_igmp_qrv = 2;
 
+   net->ipv4.sysctl_ip_mr_cache_queue_length = 10;
return 0;
 }
 
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index ddbf8c9a1abb..c6a6c3e453a9 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1127,6 +1127,7 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, 
vifi_t vifi,
 struct sk_buff *skb, struct net_device *dev)
 {
const struct iphdr *iph = ip_hdr(skb);
+   struct net *net = dev_net(dev);
struct mfc_cache *c;
bool found = false;
int err;
@@ -1142,7 +1143,8 @@ static int ipmr_cache_unresolved(struct mr_table *mrt, 
vifi_t vifi,
 
if (!found) {
/* Create a new entry if allowable */
-   if (atomic_read(>cache_resolve_queue_len) >= 10 ||
+   if (atomic_read(>cache_resolve_queue_len) >=
+   net->ipv4.sysctl_ip_mr_cache_queue_length ||
(c = ipmr_cache_alloc_unres()) == NULL) {
spin_unlock_bh(_unres_lock);
 
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index ba0fc4b18465..78ae86e8c6cb 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -784,6 +784,13 @@ static struct ctl_table ipv4_net_table[] = {
.proc_handler   = proc_dointvec
},
 #ifdef CONFIG_IP_MULTICAST
+   {
+   .procname   = "ip_mr_cache_queue_length",
+   .data   = 
_net.ipv4.sysctl_ip_mr_cache_queue_length,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec
+   },
{
.procname   = "igmp_qrv",
.data   = _net.ipv4.sysctl_igmp_qrv,
-- 
2.21.0

[PATCH 2/2] ip6mr: Make cache queue length configurable

[Brodie Greenfield]

We want to be able to keep more spaces available in our queue for
processing incoming IPv6 multicast traffic (adding (S,G) entries) - this
lets us learn more groups faster, rather than dropping them at this stage.

Signed-off-by: Brodie Greenfield 
---
 Documentation/networking/ip-sysctl.txt | 8 
 include/net/netns/ipv6.h   | 1 +
 net/ipv6/af_inet6.c| 1 +
 net/ipv6/ip6mr.c   | 4 +++-
 net/ipv6/sysctl_net_ipv6.c | 7 +++
 5 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/networking/ip-sysctl.txt 
b/Documentation/networking/ip-sysctl.txt
index 02f77e932adf..68eada3ca915 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1481,6 +1481,14 @@ skip_notify_on_dev_down - BOOLEAN
on userspace caches to track link events and evict routes.
Default: false (generate message)
 
+ip6_mr_cache_queue_length - INTEGER
+   Limit the number of multicast packets we can have in the queue to be
+   resolved.
+   Bear in mind that when an unresolved multicast packet is received,
+   there is an O(n) traversal of the queue. This should be considered
+   if increasing.
+   Default: 10
+
 IPv6 Fragmentation:
 
 ip6frag_high_thresh - INTEGER
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index ef1ed529f33c..84b58424c799 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -46,6 +46,7 @@ struct netns_sysctl_ipv6 {
int max_hbh_opts_len;
int seg6_flowlabel;
bool skip_notify_on_dev_down;
+   unsigned int ip6_mr_cache_queue_length;
 };
 
 struct netns_ipv6 {
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index d99753b5e39b..6551bb63e5a2 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -856,6 +856,7 @@ static int __net_init inet6_net_init(struct net *net)
net->ipv6.sysctl.max_hbh_opts_cnt = IP6_DEFAULT_MAX_HBH_OPTS_CNT;
net->ipv6.sysctl.max_dst_opts_len = IP6_DEFAULT_MAX_DST_OPTS_LEN;
net->ipv6.sysctl.max_hbh_opts_len = IP6_DEFAULT_MAX_HBH_OPTS_LEN;
+   net->ipv6.sysctl.ip6_mr_cache_queue_length = 10;
atomic_set(>ipv6.fib6_sernum, 1);
 
err = ipv6_init_mibs(net);
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index cc01aa3f2b5e..bb445871437e 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1135,6 +1135,7 @@ static int ip6mr_cache_report(struct mr_table *mrt, 
struct sk_buff *pkt,
 static int ip6mr_cache_unresolved(struct mr_table *mrt, mifi_t mifi,
  struct sk_buff *skb, struct net_device *dev)
 {
+   struct net *net = dev_net(dev);
struct mfc6_cache *c;
bool found = false;
int err;
@@ -1153,7 +1154,8 @@ static int ip6mr_cache_unresolved(struct mr_table *mrt, 
mifi_t mifi,
 *  Create a new entry if allowable
 */
 
-   if (atomic_read(>cache_resolve_queue_len) >= 10 ||
+   if (atomic_read(>cache_resolve_queue_len) >=
+   net->ipv6.sysctl.ip6_mr_cache_queue_length ||
(c = ip6mr_cache_alloc_unres()) == NULL) {
spin_unlock_bh(_unres_lock);
 
diff --git a/net/ipv6/sysctl_net_ipv6.c b/net/ipv6/sysctl_net_ipv6.c
index e15cd37024fd..a27299d4cc34 100644
--- a/net/ipv6/sysctl_net_ipv6.c
+++ b/net/ipv6/sysctl_net_ipv6.c
@@ -159,6 +159,13 @@ static struct ctl_table ipv6_table_template[] = {
.mode   = 0644,
.proc_handler   = proc_dointvec
},
+   {
+   .procname   = "ip6_mr_cache_queue_length",
+   .data   = 
_net.ipv6.sysctl.ip6_mr_cache_queue_length,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec
+   },
{ }
 };
 
-- 
2.21.0

Re: [PATCH v4 1/2] Provide in-kernel headers for making it easy to extend the kernel

[Masahiro Yamada]

On Thu, Mar 7, 2019 at 5:31 AM Joel Fernandes  wrote:
>
>
> > On Sat, Mar 2, 2019 at 2:00 PM kbuild test robot  wrote:
> > >
> > > Hi Joel,
> > >
> > > Thank you for the patch! Yet something to improve:
> > >
> > > [auto build test ERROR on linus/master]
> > > [also build test ERROR on v5.0-rc8]
> > > [cannot apply to next-20190301]
> > > [if your patch is applied to the wrong git tree, please drop us a note to 
> > > help improve the system]
> > >
> > > url:
> > > https://github.com/0day-ci/linux/commits/Joel-Fernandes-Google/Provide-in-kernel-headers-for-making-it-easy-to-extend-the-kernel/20190303-014850
> > > config: sh-allmodconfig (attached as .config)
> > > compiler: sh4-linux-gnu-gcc (Debian 8.2.0-11) 8.2.0
> > > reproduce:
> > > wget 
> > > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross 
> > > -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # save the attached .config to linux build tree
> > > GCC_VERSION=8.2.0 make.cross ARCH=sh
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > > >> find: 'arch/sh/kernel/module.lds': No such file or directory
> > > >> find: 'arch/sh/kernel/module.lds': No such file or directory
> On Sun, Mar 03, 2019 at 08:11:59AM -0800, Joel Fernandes wrote:
> > This report is for an older version of the patch so ignore it. The
> > issue is already resolved.
> >
>
> Apologies, this issue is real. However it does not cause any failure. It is
> only causing find command to be a bit noisy.
>
> The below diff fixes it and I'll update the patch for v5:



Let's take a look a little bit closer.


$ find  arch  -name module.lds
arch/ia64/module.lds
arch/powerpc/kernel/module.lds
arch/riscv/kernel/module.lds
arch/arm/kernel/module.lds
arch/m68k/kernel/module.lds
arch/arm64/kernel/module.lds



(1) module.lds may not exist for some architectures
(2) module.lds may be located in a different directory (ia64)

Your fix-up missed (2).







> diff --git a/scripts/gen_ikh_data.sh b/scripts/gen_ikh_data.sh
> index 1fa5628fcc30..9a7ea856acbc 100755
> --- a/scripts/gen_ikh_data.sh
> +++ b/scripts/gen_ikh_data.sh
> @@ -1,5 +1,6 @@
>  #!/bin/bash
>  # SPDX-License-Identifier: GPL-2.0
> +set -e
>
>  spath="$(dirname "$(readlink -f "$0")")"
>  kroot="$spath/.."
> @@ -11,12 +12,14 @@ file_list=${@:2}
>
>  src_file_list=""
>  for f in $file_list; do
> +   if [ ! -f "$kroot/$f" ] && [ ! -d "$kroot/$f" ]; then continue; fi
> src_file_list="$src_file_list $(echo $f | grep -v OBJDIR)"
>  done
>
>  obj_file_list=""
>  for f in $file_list; do
> f=$(echo $f | grep OBJDIR | sed -e 's/OBJDIR\///g')
> +   if [ ! -f $f ] && [ ! -d $f ]; then continue; fi
> obj_file_list="$obj_file_list $f";
>  done
>
> --
> 2.21.0.352.gf09ad66450-goog
>

--
Best Regards
Masahiro Yamada

Re: [PULL REQUEST] Kernel lockdown patches for 5.2

[Matthew Garrett]

On Wed, Mar 6, 2019 at 7:56 PM Mimi Zohar  wrote:
> The kexec and kernel modules patches in this patch set continues to
> ignore IMA.  This patch set should up front either provide an
> alternative solution to coordinate the different signature
> verification methods or rely on the architecture specific policy for
> that coordination.

Hi Mimi,

I'm working on a patch for this at the moment which can then be added
to either patchset. Is there a tree that contains the proposed Power
architecture policy? I want to make sure I don't accidentally end up
depending on anything x86.

Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers

[Paul Gortmaker]

[Re: [PATCH v5 00/18] mfd: demodularization of non-modular drivers] On 
07/03/2019 (Thu 00:10) Pavel Machek wrote:

> On Wed 2019-01-16 13:24:31, Lee Jones wrote:
> > [...]
> > 
> > > Paul Gortmaker (18):
> > >   mfd: aat2870-core: Make it explicitly non-modular
> > >   mfd: adp5520: Make it explicitly non-modular
> > >   mfd: as3711: Make it explicitly non-modular
> > >   mfd: db8500-prcmu: drop unused MODULE_ tags from non-modular code
> > >   mfd: htc-i2cpld: Make it explicitly non-modular
> > >   mfd: max8925-core: drop unused MODULE_ tags from non-modular code
> > >   mfd: rc5t583: Make it explicitly non-modular
> > >   mfd: sta2x11: drop unused MODULE_ tags from non-modular code
> > >   mfd: syscon: Make it explicitly non-modular
> > >   mfd: tps65090: Make it explicitly non-modular
> > >   mfd: tps65910: Make it explicitly non-modular
> > >   mfd: tps80031: Make it explicitly non-modular
> > >   mfd: wm831x-spi: Make it explicitly non-modular
> > >   mfd: wm831x-i2c: Make it explicitly non-modular
> > >   mfd: wm831x-core: drop unused module infrastructure from non-modular 
> > > code
> > >   mfd: wm8350-i2c: Make it explicitly non-modular
> > >   mfd: wm8350-core: drop unused module infrastructure from non-modular 
> > > code
> > >   mfd: wm8400-core: Make it explicitly non-modular
> > > 
> > >  drivers/mfd/aat2870-core.c  | 40 
> > > +++-
> > >  drivers/mfd/adp5520.c   | 30 +++---
> > >  drivers/mfd/as3711.c| 14 --
> > >  drivers/mfd/db8500-prcmu.c  | 10 --
> > >  drivers/mfd/htc-i2cpld.c| 18 +-
> > >  20 files changed, 41 insertions(+), 332 deletions(-)
> > 
> > All applied!
> 
> Is it good idea?

Pavel, I think yes it is good, and I hope you will allow me the chance
to convince you of the same.  It removes dead code, and removes the
chance that people mistakenly believe any of these drivers were
currently possible as modules, when they were really NOT at all modular.

> We want distro kernels on ARM, too, which means people will eventually
> want these as a modules, no?

And at the risk of repeating something I've said a lot already, this
is fine, and I 100% support people converting drivers to being modular,
in the case where there is demand, and where people with the hardware
who are willing to test that the modular use-case actually works.

If people want it to be modular, then this work actually helps.  You
don't have drivers "hiding in the shadows" that pretend to be modules.
Such drivers do not at all help with the "distro kernels" use case.

If a driver author responds and says they intended to make their driver
a module, I 100% support them, and will drop the code removal patch and
also have supported them in making their work tristate.  If the choice
to convert to tristate happens a year or more from now, it is trivial to
reclaim the unused-but-deleted code from git.

But, again as I have said many times -- I can't know every detail of
each driver to know if module/tristate makes any sense, as a use-case or
if even technically possible (such as in DMA/IOMMU or similar low level
core systems).   So the right option is to remove the dead code and not
impact the existing driver behaviour, and make it clear in the process
to the authors and users, that the driver was never modular to begin
with --  and in doing so, give them all a chance to comment and react.

Pavel, I hope this more extended explanation makes sense to you, and
that you simply have not seen me write these same details in the past.

Thanks,
Paul.
--

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

Re: [PATCH] kbuild: add workaround for Debian make-kpkg

[Masahiro Yamada]

On Thu, Mar 7, 2019 at 6:02 AM Ben Hutchings  wrote:
>
> [Trying again with an alternate address for Manoj.]
>
> kernel-package is maintained by Manoj Srivastava (cc'd), not by the
> Debian kernel team.
>
> On Thu, 2019-03-07 at 01:00 +0900, Masahiro Yamada wrote:
> > Since commit 3812b8c5c5d5 ("kbuild: make -r/-R effective in top
> > Makefile for old Make versions"), make-kpkg is not working.
> >
> > make-kpkg directly includes the top Makefile of Linux kernel, and
> > appends some debian_* targets.
> >
> >   /usr/share/kernel-package/ruleset/kernel_version.mk:
> >
> > # Include the kernel makefile
> > override dot-config := 1
> > include Makefile
> > dot-config := 1
> >
> > I did not know the kernel Makefile was used in that way, and it is
> > hard to guarantee the behavior when the kernel Makefile is included
> > by another Makefile from a different project.
> >
> > Looks like Debian Stretch stopped providing make-kpkg (except
> > PowerPC).
>
> kernel-package is not included in stretch at all.  I'm not sure where
> you're seeing it as being present on powerpc - that architecture wasn't
> included in the stretch release.


Actually, I have not checked the powerpc part by myself.


I just read the following page:

https://unix.stackexchange.com/questions/238469/difference-between-make-kpkg-and-make-deb-pkg


"make-kpkg is included in wheezy and jessie but stretch (current
stable) only contains it for powerpc.

Powerpc is no longer supported in buster (testing)"



I will drop the PowerPC part.




> > Maybe it is obsolete and being replaced with 'make deb-pkg' etc.
> > but still widely used.
> [...]
>
> kernel-package is currently planned to be included in the next release,
> though I'm not sure whether it should be.

Hmm, OK.

I checked debian:buster in Docker,
and I see it.


root@3382de16960a:/home/foo# apt-file search  make-kpkg
kernel-package: /usr/bin/make-kpkg
kernel-package: /usr/share/man/man1/make-kpkg.1.gz
zsh-common: /usr/share/zsh/functions/Completion/Debian/_make-kpkg




If make-kpkg will still be included in the future Debian releases,
I'd like to change make-kpkg to make it work more reliably.


The git URL in the control file
"https://anonscm.debian.org/git/users/srivasta/debian/kernel-package.git;
seems stale.

Anyway, I found it in a new place:

$ git clone  https://salsa.debian.org/srivasta/kernel-package


Hmm, the last commit was three years ago.

So, it is almost unmaintained, I guess...


> There is another bug report about kernel-package with current kernel
> versions  but I don't know whether it
> has been worked around already.

Probably, not fixed.

It is not stalled actually.
I guess make-kpkg is hiding messages sent to stdout for some reasons.
If you continue pressing "Enter" key,
it will move on to the build stage.

I will take a look if it should be maintained.



Anyway, I want to hear from Manoj.


--
Best Regards
Masahiro Yamada

Re: [PATCH v2] fs: cifs: Kconfig: pedantic formatting

[Steve French]

Is this just converting spaces to tabs?

Looks identical at first glance otherwise (see screenshot)

On Wed, Mar 6, 2019 at 4:23 PM Enrico Weigelt, metux IT consult
 wrote:
>
> Formatting of Kconfig files doesn't look so pretty, so just
> take damp cloth and clean it up.
>
> Signed-off-by: Enrico Weigelt, metux IT consult 
> ---
>  fs/cifs/Kconfig | 120 
> 
>  1 file changed, 60 insertions(+), 60 deletions(-)
>
> diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
> index f1ddc9d..76724ef 100644
> --- a/fs/cifs/Kconfig
> +++ b/fs/cifs/Kconfig
> @@ -117,25 +117,25 @@ config CIFS_UPCALL
>   secure Kerberos authentication is required). If unsure, say Y.
>
>  config CIFS_XATTR
> -bool "CIFS extended attributes"
> -depends on CIFS
> -help
> -  Extended attributes are name:value pairs associated with inodes by
> -  the kernel or by users (see the attr(5) manual page for details).
> -  CIFS maps the name of extended attributes beginning with the user
> -  namespace prefix to SMB/CIFS EAs.  EAs are stored on Windows
> -  servers without the user namespace prefix, but their names are
> -  seen by Linux cifs clients prefaced by the user namespace prefix.
> -  The system namespace (used by some filesystems to store ACLs) is
> -  not supported at this time.
> -
> -  If unsure, say Y.
> +   bool "CIFS extended attributes"
> +   depends on CIFS
> +   help
> + Extended attributes are name:value pairs associated with inodes by
> + the kernel or by users (see the attr(5) manual page for details).
> + CIFS maps the name of extended attributes beginning with the user
> + namespace prefix to SMB/CIFS EAs.  EAs are stored on Windows
> + servers without the user namespace prefix, but their names are
> + seen by Linux cifs clients prefaced by the user namespace prefix.
> + The system namespace (used by some filesystems to store ACLs) is
> + not supported at this time.
> +
> + If unsure, say Y.
>
>  config CIFS_POSIX
> -bool "CIFS POSIX Extensions"
> -depends on CIFS && CIFS_ALLOW_INSECURE_LEGACY && CIFS_XATTR
> -help
> -  Enabling this option will cause the cifs client to attempt to
> +   bool "CIFS POSIX Extensions"
> +   depends on CIFS && CIFS_ALLOW_INSECURE_LEGACY && CIFS_XATTR
> +   help
> + Enabling this option will cause the cifs client to attempt to
>   negotiate a newer dialect with servers, such as Samba 3.0.5
>   or later, that optionally can handle more POSIX like (rather
>   than Windows like) file behavior.  It also enables
> @@ -144,61 +144,62 @@ config CIFS_POSIX
>   CIFS POSIX ACL support.  If unsure, say N.
>
>  config CIFS_ACL
> - bool "Provide CIFS ACL support"
> - depends on CIFS_XATTR && KEYS
> - help
> -   Allows fetching CIFS/NTFS ACL from the server.  The DACL blob
> -   is handed over to the application/caller.  See the man
> -   page for getcifsacl for more information.  If unsure, say Y.
> +   bool "Provide CIFS ACL support"
> +   depends on CIFS_XATTR && KEYS
> +   help
> + Allows fetching CIFS/NTFS ACL from the server.  The DACL blob
> + is handed over to the application/caller.  See the man
> + page for getcifsacl for more information.  If unsure, say Y.
>
>  config CIFS_DEBUG
> bool "Enable CIFS debugging routines"
> default y
> depends on CIFS
> help
> -  Enabling this option adds helpful debugging messages to
> -  the cifs code which increases the size of the cifs module.
> -  If unsure, say Y.
> + Enabling this option adds helpful debugging messages to
> + the cifs code which increases the size of the cifs module.
> + If unsure, say Y.
> +
>  config CIFS_DEBUG2
> bool "Enable additional CIFS debugging routines"
> depends on CIFS_DEBUG
> help
> -  Enabling this option adds a few more debugging routines
> -  to the cifs code which slightly increases the size of
> -  the cifs module and can cause additional logging of debug
> -  messages in some error paths, slowing performance. This
> -  option can be turned off unless you are debugging
> -  cifs problems.  If unsure, say N.
> + Enabling this option adds a few more debugging routines
> + to the cifs code which slightly increases the size of
> + the cifs module and can cause additional logging of debug
> + messages in some error paths, slowing performance. This
> + option can be turned off unless you are debugging
> + cifs problems.  If unsure, say N.
>
>  config CIFS_DEBUG_DUMP_KEYS
> bool "Dump encryption keys for offline decryption 

Re: [PULL REQUEST] Kernel lockdown patches for 5.2

[Mimi Zohar]

On Wed, 2019-03-06 at 15:58 -0800, Matthew Garrett wrote:

> 3) The integration with IMA has been dropped for now. IMA is in the
> process of adding support for architecture-specific policies that will
> interact correctly with the lockdown feature, and a followup patch will
> integrate that so we don't end up with an ordering dependency on the
> merge

The architecture specific policy is an attempt to coordinate between
the different signature verification methods (eg. PE and IMA kexec
kernel image signatures, appended and IMA kernel module signatures).
 The coordination between these signature verification methods is
independent of the "lockdown" feature.

To prevent requiring multiple signature verifications, an IMA policy
rule(s) is defined only if either KEXEC_VERIFY_SIG or MODULE_SIG is
not enabled.

The kexec and kernel modules patches in this patch set continues to
ignore IMA.  This patch set should up front either provide an
alternative solution to coordinate the different signature
verification methods or rely on the architecture specific policy for
that coordination.

Mimi

[PATCH] powerpc: silence unused-but-set-variable warnings

[Qian Cai]

pte_unmap() compiles away on some powerpc platforms, so silence the
warnings below by using the argument to pte_unmap() as a nop. Also, fix
checkpatch.pl warnings "Single statement macros should not use a do {}
while (0) loop".

mm/memory.c: In function 'copy_pte_range':
mm/memory.c:820:24: warning: variable 'orig_dst_pte' set but not used
[-Wunused-but-set-variable]
mm/memory.c:820:9: warning: variable 'orig_src_pte' set but not used
[-Wunused-but-set-variable]
mm/madvise.c: In function 'madvise_free_pte_range':
mm/madvise.c:318:9: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]
mm/swap_state.c: In function 'swap_ra_info':
mm/swap_state.c:634:15: warning: variable 'orig_pte' set but not used
[-Wunused-but-set-variable]

Signed-off-by: Qian Cai 
---
 arch/powerpc/include/asm/book3s/64/pgtable.h | 2 +-
 arch/powerpc/include/asm/nohash/64/pgtable.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h 
b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 868fcaf56f6b..ec00ce6dd312 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -1006,7 +1006,7 @@ extern struct page *pgd_page(pgd_t pgd);
(((pte_t *) pmd_page_vaddr(*(dir))) + pte_index(addr))
 
 #define pte_offset_map(dir,addr)   pte_offset_kernel((dir), (addr))
-#define pte_unmap(pte) do { } while(0)
+#define pte_unmap(pte) (void)(pte)
 
 /* to find an entry in a kernel page-table-directory */
 /* This now only contains the vmalloc pages */
diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h 
b/arch/powerpc/include/asm/nohash/64/pgtable.h
index e77ed9761632..103071afab3d 100644
--- a/arch/powerpc/include/asm/nohash/64/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/64/pgtable.h
@@ -205,7 +205,7 @@ static inline void pgd_set(pgd_t *pgdp, unsigned long val)
   (((pte_t *) pmd_page_vaddr(*(dir))) + (((addr) >> PAGE_SHIFT) & 
(PTRS_PER_PTE - 1)))
 
 #define pte_offset_map(dir,addr)   pte_offset_kernel((dir), (addr))
-#define pte_unmap(pte) do { } while(0)
+#define pte_unmap(pte) (void)(pte)
 
 /* to find an entry in a kernel page-table-directory */
 /* This now only contains the vmalloc pages */
-- 
2.17.2 (Apple Git-113)

Re: [PATCH] habanalabs: use %px instead of %p in error print

[Kees Cook]

On Sat, Mar 2, 2019 at 1:43 AM Oded Gabbay  wrote:
>
> When parsing the address of an internal command buffer, the driver prints
> an error if the buffer's address is not in the range of the device's DRAM
> or SRAM memory address space.
>
> Use %px to print the real address that the user gave the driver and not a
> hashed value, so the user will get a clue regarding the origin of his
> error.
>
> Note that if the print occurs, the pointer that is printed is a
> user's virtual address and not some kind of physical address.

Err, which virtual address space is this? If this is mapped into the
kernel's virtual address space, this should not be %px...

-Kees

>
> Suggested-by: Joe Perches 
> Signed-off-by: Oded Gabbay 
> ---
>  drivers/misc/habanalabs/goya/goya.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/habanalabs/goya/goya.c 
> b/drivers/misc/habanalabs/goya/goya.c
> index c4f3ec1e9d8b..238dd57c541b 100644
> --- a/drivers/misc/habanalabs/goya/goya.c
> +++ b/drivers/misc/habanalabs/goya/goya.c
> @@ -4293,7 +4293,7 @@ static int goya_parse_cb_no_ext_quque(struct hl_device 
> *hdev,
> return 0;
>
> dev_err(hdev->dev,
> -   "Internal CB address %p + 0x%x is not in SRAM nor in 
> DRAM\n",
> +   "Internal CB address %px + 0x%x is not in SRAM nor in 
> DRAM\n",
> parser->user_cb, parser->user_cb_size);
>
> return -EFAULT;
> --
> 2.18.0
>


-- 
Kees Cook

Re: [RFC] LKML Archive in Maildir Format

[Eric Wong]

Bjorn Helgaas  wrote:
> On Tue, Mar 5, 2019 at 5:26 PM Eric Wong  wrote:
> > Bjorn Helgaas  wrote:
> 
> > > Any pointers?  I guess there's no mutt backend that can read a
> > > public-inbox archive directly?
> >
> > There's mutt patches to support reading over NNTP, so that
> > works:
> >
> > mutt -f news://$INBOX_HOST/$INBOX_NEWSGROUP
> 
> Neomutt includes NNTP support, so I tried this:
> 
>   neomutt -f news://nntp.lore.kernel.org/org.kernel.vger.linux-kernel
> 
> which worked OK but (1) I only see the most recent 1000 messages and
> (2) obviously isn't reading a *local* archive.  Neomutt took about 45
> seconds to start up over my wimpy ISP.
> 
> I assume I could probably have a local archive and run a local NNTP
> server and point neomutt at that local server.  But I don't know how
> full-archive searching would work there.

Right.  AFAIK there isn't a good solution for search via NNTP.

> > I don't think mutt handles mboxrd 100% correctly, but it's close
> > enough that you can can download the gzipped mboxrd of a search
> > query and open it via "mutt -f /path/to/downloaded/mbox.gz"
> >
> >   curl -XPOST -OJ "$INBOX_URL/?q=$SEARCH_QUERY=m"
> 
> I got nothing at all with -XPOST, but this:

Ah, I guess nginx (or something in AWS) rejects POST without
Content-Length headers.  Adding "-HContent-Length:0"
to the command-line with -XPOST works for lore.

>   curl -OJ "https://lore.kernel.org/linux-pci/?q=d:20190301..=m;
> 
> got me the HTML source.  Nothing that looks like mboxrd.  I assume

Right.  The "x=m" requests an mbox; but it's only available via
POST requests (to prevent search engine spiders from wasting
time on non-HTML content).  With the HTML output in a browser,
the "mbox.gz" button makes the POST request and allows you to
download the mbox.

> this is stupid user error on my part, but even with that resolved, it
> wouldn't have the nice git fetch properties of the git archive, i.e.,
> incremental updates of only new stuff, would it?

You could bump d:MMDD (there's also "dt:" for date-time if
you need more precision).

> I think my ideal solution would be a mutt that could read the git
> archive directly, plus a notmuch index.  But AFAIK, mutt can't do
> that, and notmuch only works with one message per file, not with the
> git archive.
> 
> Something that might work would be to use Konstantin's "git archive to
> maildir" hint but shard into a bunch of smaller maildirs instead of
> one big one, then have notmuch index those, and use mutt or vim with
> notmuch queries instead of having it read in a maildir.

Small Maildirs work great, but large ones fall over.  I don't
think having a bunch of smaller Maildirs would help notmuch
since notmuch still needs to know each file path.

The only way I could see notmuch/Maildir working well is to keep
the overall number of messages relatively small.

One of my longer-term goals is to write a mairix-like tool in
Perl which works with public-inbox archives; but I barely have
enough time for public-inbox these days :<

mairix works with gzipped mboxes, which is great for large
archives; but the indexing falls over since it rewrites the
entire search index every time. SSDs have died as a result :<

> But I feel like I must be missing the solution that's obvious to
> everybody but me.

Nope, you're not alone :)  There's not a lot of mail software
which can handle LKML-sized histories efficiently.

[PATCH 3/3] arm64: dts: imx8mq: add osc_hdmi_phy_27m fixed clock

[Anson Huang]

Add new fixed clock osc_hdmi_phy_27m.

Signed-off-by: Anson Huang 
---
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi 
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 8e9d6d5..fbcdd4d 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -48,6 +48,13 @@
clock-output-names = "osc_27m";
};
 
+   osc_hdmi_phy_27m: clock-osc-hdmi-phy-27m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2700>;
+   clock-output-names = "osc_hdmi_phy_27m";
+   };
+
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
-- 
2.7.4

[PATCH 2/3] clk: imx8mq: add hdmi_phy_27m clock as pll's reference clock

[Anson Huang]

There is another 27MHz OSC inside i.MX8MQ's display block and
it can be one of reference clocks of all PLLs, add it into clock
tree and also add it as PLL's reference clock.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx8mq.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8mq.c b/drivers/clk/imx/clk-imx8mq.c
index a9b3888..bb1bf9b 100644
--- a/drivers/clk/imx/clk-imx8mq.c
+++ b/drivers/clk/imx/clk-imx8mq.c
@@ -26,7 +26,7 @@ static u32 share_count_nand;
 
 static struct clk *clks[IMX8MQ_CLK_END];
 
-static const char * const pll_ref_sels[] = { "osc_25m", "osc_27m", "dummy", 
"dummy", };
+static const char * const pll_ref_sels[] = { "osc_25m", "osc_27m", 
"osc_hdmi_phy_27m", "dummy", };
 static const char * const arm_pll_bypass_sels[] = {"arm_pll", 
"arm_pll_ref_sel", };
 static const char * const gpu_pll_bypass_sels[] = {"gpu_pll", 
"gpu_pll_ref_sel", };
 static const char * const vpu_pll_bypass_sels[] = {"vpu_pll", 
"vpu_pll_ref_sel", };
@@ -281,6 +281,7 @@ static int imx8mq_clocks_probe(struct platform_device *pdev)
clks[IMX8MQ_CLK_32K] = of_clk_get_by_name(np, "ckil");
clks[IMX8MQ_CLK_25M] = of_clk_get_by_name(np, "osc_25m");
clks[IMX8MQ_CLK_27M] = of_clk_get_by_name(np, "osc_27m");
+   clks[IMX8MQ_CLK_HDMI_PHY_27M] = of_clk_get_by_name(np, 
"osc_hdmi_phy_27m");
clks[IMX8MQ_CLK_EXT1] = of_clk_get_by_name(np, "clk_ext1");
clks[IMX8MQ_CLK_EXT2] = of_clk_get_by_name(np, "clk_ext2");
clks[IMX8MQ_CLK_EXT3] = of_clk_get_by_name(np, "clk_ext3");
-- 
2.7.4

[PATCH 1/3] dt-bindings: clock: imx8mq: add hdmi phy 27m clock

[Anson Huang]

Add IMX8MQ_CLK_HDMI_PHY_27M clock for i.MX8MQ clock tree.

Signed-off-by: Anson Huang 
---
 include/dt-bindings/clock/imx8mq-clock.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/dt-bindings/clock/imx8mq-clock.h 
b/include/dt-bindings/clock/imx8mq-clock.h
index b58cc64..f50ef4e9 100644
--- a/include/dt-bindings/clock/imx8mq-clock.h
+++ b/include/dt-bindings/clock/imx8mq-clock.h
@@ -400,5 +400,7 @@
 #define IMX8MQ_CLK_GPIO4_ROOT  273
 #define IMX8MQ_CLK_GPIO5_ROOT  274
 
-#define IMX8MQ_CLK_END 275
+#define IMX8MQ_CLK_HDMI_PHY_27M275
+
+#define IMX8MQ_CLK_END 276
 #endif /* __DT_BINDINGS_CLOCK_IMX8MQ_H */
-- 
2.7.4

Re: [PATCH 4/5] Add driver for SUNIX Multi-I/O board

[Enrico Weigelt, metux IT consult]

On 27.02.19 08:18, Morris Ku wrote:

Hi,


first of all: the code is pretty unreadable. I doubt that anybody here
seriously likes to review that (nor take it into mainline).

Formatting should be consistent - see other drivers.

./scripts/checkpatch.pl is your friend. You really shut run it and fix
everything it complaints before posting patches. (some maintainers can
get angry if you don't ;-)

> Support SUNIX serial board.
> 
> ---
>  char/snx/snx_serial.c | 4771 +
>  1 file changed, 4771 insertions(+)
>  create mode 100644 char/snx/snx_serial.c
> 
> diff --git a/char/snx/snx_serial.c b/char/snx/snx_serial.c
> new file mode 100644
> index ..94caac1a
> --- /dev/null
> +++ b/char/snx/snx_serial.c
> @@ -0,0 +1,4771 @@
> +#include "snx_common.h"
> +#include "driver_extd.h"
> +
> +#define SNX_ioctl_DBG0
> +#define  EEPROM_ACCESS_DELAY_COUNT   10

is this eeprom stuff really specific to the serial ports ?
if not, it probably should go to a separate file, which is called by all
the others, IMHO.

> +
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 37))
> + static DEFINE_SEMAPHORE(ser_port_sem);
> +#else
> + static DECLARE_MUTEX(ser_port_sem);
> +#endif

Drop that. We have only one kernel version here, the current one.

> +
> +
> +#define SNX_HIGH_BITS_OFFSET ((sizeof(long)-sizeof(int))*8)
> +#define sunix_ser_users(state)   ((state)->count + ((state)->info ? 
> (state)->info->blocked_open : 0))
> +
> +
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 7, 0))
> +static struct tty_port snx_service_port;
> +#endif

are you really sure this has to be a global field, instead of allocated
per-device ?

> +
> +
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(3, 7, 0))
> +
> +struct serial_uart_config {
> + char*name;
> + int dfl_xmit_fifo_size;
> + int flags;
> +};
> +#endif
> +
> +static const struct serial_uart_config snx_uart_config[PORT_SER_MAX_UART + 
> 1] = {

why +1 ?

maybe PORT_SER_MAX_UART and use ARRAY_SIZE() macro instead.

> + { "unknown",1,  0 },
> + { "8250",   1,  0 },
> + { "16450",  1,  0 },
> + { "16550",  1,  0 },
> + { "16550A", 16, UART_CLEAR_FIFO | UART_USE_FIFO },
> + { "Cirrus", 1,  0 },
> + { "ST16650",1,  0 },
> + { "ST16650V2",  32, UART_CLEAR_FIFO | UART_USE_FIFO },
> + { "TI16750",64, UART_CLEAR_FIFO | UART_USE_FIFO },
> +};
>
> +
> +
> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 0))
> +static int   sunix_ser_refcount;
> +static struct tty_struct 
> *sunix_ser_tty[SNX_SER_TOTAL_MAX + 1];
> +static struct termios
> *sunix_ser_termios[SNX_SER_TOTAL_MAX + 1];
> +static struct termios
> *sunix_ser_termios_locked[SNX_SER_TOTAL_MAX + 1];
> +#endif

obsolete. drop that.

> +
> +
> +static _INLINE_ void snx_ser_handle_cts_change(struct snx_ser_port *, 
> unsigned int);

what exactly does _INLINE_ suppose to mean ?



> +extern int   sunix_ser_interrupt(struct sunix_board *, struct 
> sunix_ser_port *);

why "extern" here ? where is that function coming from ?



> +static unsigned char READ_INTERRUPT_VECTOR_BYTE(struct sunix_ser_port *);

I doubt that upper case function names fit in the kernel coding style.



> + case SNX_SER_DUMP_PORT_INFO:
> + {
> + int i;
> + struct snx_ser_port_info 
> snx_port_info[SNX_SER_TOTAL_MAX];
> + struct snx_ser_port *sdn = NULL;
> +
> + memset(snx_port_info, 0, (sizeof(struct 
> snx_ser_port_info) * SNX_SER_TOTAL_MAX));
> +
> + if (line == 0) {
> + for (i = 0; i < SNX_SER_TOTAL_MAX; i++) {
> + sdn = (struct snx_ser_port *) 
> _ser_table[i];
> +
> + 
> memcpy(_port_info[i].board_name_info[0], >pb_info.board_name[0], 
> SNX_BOARDNAME_LENGTH);
> +
> + snx_port_info[i].bus_number_info = 
> sdn->bus_number;
> + snx_port_info[i].dev_number_info = 
> sdn->dev_number;
> + snx_port_info[i].port_info   = 
> sdn->line;
> + snx_port_info[i].base_info   = 
> sdn->iobase;
> + snx_port_info[i].irq_info= 
> sdn->irq;
> + }
> +
> + if (copy_to_user((void *)arg, snx_port_info, 
> SNX_SER_TOTAL_MAX * sizeof(struct snx_ser_port_info))) {
> + ret = -EFAULT;
> + } else {
> + ret = 0;
> + }
> + } else {
> + 

Re: [PATCH v4 3/3] i2c: mediatek: Add i2c support for MediaTek MT8183

[Qii Wang]

I am sorry to have missed some comment, and reply the mail again.

On Wed, 2019-02-20 at 15:41 +0100, Matthias Brugger wrote:
> 
> On 20/02/2019 13:33, Qii Wang wrote:
> > Add i2c compatible for MT8183. Compare to MT2712 i2c controller,
> > MT8183 has different registers, offsets and clock.
> > 
> > Signed-off-by: Qii Wang 
> 
> So you introduce arb clock, ltiming (what is this exactly) and the new SoC in
> one commit. I'd prefer to split that up and explain shortly in the commit
> message why they are needed. More comments inline.
> 

I have split this patch into three in V5.

> > ---
> >  drivers/i2c/busses/i2c-mt65xx.c |   89 
> > ---
> >  1 file changed, 84 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-mt65xx.c 
> > b/drivers/i2c/busses/i2c-mt65xx.c
> > index 428ac99..82eedbd 100644
> > --- a/drivers/i2c/busses/i2c-mt65xx.c
> > +++ b/drivers/i2c/busses/i2c-mt65xx.c
> > @@ -35,6 +35,7 @@
> >  #include 
> >  
> >  #define I2C_RS_TRANSFER(1 << 4)
> > +#define I2C_ARB_LOST   (1 << 3)
> >  #define I2C_HS_NACKERR (1 << 2)
> >  #define I2C_ACKERR (1 << 1)
> >  #define I2C_TRANSAC_COMP   (1 << 0)
> > @@ -76,6 +77,8 @@
> >  #define I2C_CONTROL_DIR_CHANGE  (0x1 << 4)
> >  #define I2C_CONTROL_ACKERR_DET_EN   (0x1 << 5)
> >  #define I2C_CONTROL_TRANSFER_LEN_CHANGE (0x1 << 6)
> > +#define I2C_CONTROL_DMAACK_EN   (0x1 << 8)
> > +#define I2C_CONTROL_ASYNC_MODE  (0x1 << 9)
> >  #define I2C_CONTROL_WRAPPER (0x1 << 0)
> >  
> >  #define I2C_DRV_NAME   "i2c-mt65xx"
> > @@ -130,6 +133,8 @@ enum I2C_REGS_OFFSET {
> > OFFSET_DEBUGCTRL,
> > OFFSET_TRANSFER_LEN_AUX,
> > OFFSET_CLOCK_DIV,
> > +   /* MT8183 only regs */
> > +   OFFSET_LTIMING,
> >  };
> >  
> >  static const u16 mt_i2c_regs_v1[] = {
> > @@ -159,6 +164,32 @@ enum I2C_REGS_OFFSET {
> > [OFFSET_CLOCK_DIV] = 0x70,
> >  };
> >  
> > +static const u16 mt_i2c_regs_v2[] = {
> > +   [OFFSET_DATA_PORT] = 0x0,
> > +   [OFFSET_SLAVE_ADDR] = 0x4,
> > +   [OFFSET_INTR_MASK] = 0x8,
> > +   [OFFSET_INTR_STAT] = 0xc,
> > +   [OFFSET_CONTROL] = 0x10,
> > +   [OFFSET_TRANSFER_LEN] = 0x14,
> > +   [OFFSET_TRANSAC_LEN] = 0x18,
> > +   [OFFSET_DELAY_LEN] = 0x1c,
> > +   [OFFSET_TIMING] = 0x20,
> > +   [OFFSET_START] = 0x24,
> > +   [OFFSET_EXT_CONF] = 0x28,
> > +   [OFFSET_LTIMING] = 0x2c,
> > +   [OFFSET_HS] = 0x30,
> > +   [OFFSET_IO_CONFIG] = 0x34,
> > +   [OFFSET_FIFO_ADDR_CLR] = 0x38,
> > +   [OFFSET_TRANSFER_LEN_AUX] = 0x44,
> > +   [OFFSET_CLOCK_DIV] = 0x48,
> > +   [OFFSET_SOFTRESET] = 0x50,
> > +   [OFFSET_DEBUGSTAT] = 0xe0,
> > +   [OFFSET_DEBUGCTRL] = 0xe8,
> > +   [OFFSET_FIFO_STAT] = 0xf4,
> > +   [OFFSET_FIFO_THRESH] = 0xf8,
> > +   [OFFSET_DCM_EN] = 0xf88,
> > +};
> > +
> >  struct mtk_i2c_compatible {
> > const struct i2c_adapter_quirks *quirks;
> > const u16 *regs;
> > @@ -168,6 +199,7 @@ struct mtk_i2c_compatible {
> > unsigned char aux_len_reg: 1;
> > unsigned char support_33bits: 1;
> > unsigned char timing_adjust: 1;
> > +   unsigned char dma_sync: 1;
> >  };
> >  
> >  struct mtk_i2c {
> > @@ -181,6 +213,7 @@ struct mtk_i2c {
> > struct clk *clk_main;   /* main clock for i2c bus */
> > struct clk *clk_dma;/* DMA clock for i2c via DMA */
> > struct clk *clk_pmic;   /* PMIC clock for i2c from PMIC */
> > +   struct clk *clk_arb;/* Arbitrator clock for i2c */
> > bool have_pmic; /* can use i2c pins from PMIC */
> > bool use_push_pull; /* IO config push-pull mode */
> >  
> > @@ -190,6 +223,7 @@ struct mtk_i2c {
> > enum mtk_trans_op op;
> > u16 timing_reg;
> > u16 high_speed_reg;
> > +   u16 ltiming_reg;
> > unsigned char auto_restart;
> > bool ignore_restart_irq;
> > const struct mtk_i2c_compatible *dev_comp;
> > @@ -216,6 +250,7 @@ struct mtk_i2c {
> > .aux_len_reg = 1,
> > .support_33bits = 1,
> > .timing_adjust = 1,
> > +   .dma_sync = 0,
> >  };
> >  
> >  static const struct mtk_i2c_compatible mt6577_compat = {
> > @@ -227,6 +262,7 @@ struct mtk_i2c {
> > .aux_len_reg = 0,
> > .support_33bits = 0,
> > .timing_adjust = 0,
> > +   .dma_sync = 0,
> >  };
> >  
> >  static const struct mtk_i2c_compatible mt6589_compat = {
> > @@ -238,6 +274,7 @@ struct mtk_i2c {
> > .aux_len_reg = 0,
> > .support_33bits = 0,
> > .timing_adjust = 0,
> > +   .dma_sync = 0,
> >  };
> >  
> >  static const struct mtk_i2c_compatible mt7622_compat = {
> > @@ -249,6 +286,7 @@ struct mtk_i2c {
> > .aux_len_reg = 1,
> > .support_33bits = 0,
> > .timing_adjust = 0,
> > +   .dma_sync = 0,
> >  };
> >  
> >  static const struct mtk_i2c_compatible mt8173_compat = {
> > @@ -259,6 +297,18 @@ struct mtk_i2c {
> > .aux_len_reg = 1,
> > .support_33bits = 1,
> > .timing_adjust = 0,
> > +   

Re: [PATCH] vhost: silence an unused-variable warning

[Jason Wang]

On 2019/3/6 下午7:05, Arnd Bergmann wrote:

On some architectures, the MMU can be disabled, leading to access_ok()
becoming an empty macro that does not evaluate its size argument,
which in turn produces an unused-variable warning:

drivers/vhost/vhost.c:1191:9: error: unused variable 's' 
[-Werror,-Wunused-variable]
 size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;

Mark the variable as __maybe_unused to shut up that warning.

Signed-off-by: Arnd Bergmann 
---
  drivers/vhost/vhost.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index a2e5dc7716e2..5ace833de746 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -1188,7 +1188,7 @@ static bool vq_access_ok(struct vhost_virtqueue *vq, 
unsigned int num,
 struct vring_used __user *used)
  
  {

-   size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
+   size_t s __maybe_unused = vhost_has_feature(vq, 
VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
  
  	return access_ok(desc, num * sizeof *desc) &&

   access_ok(avail,



Acked-by: Jason Wang 

Re: [m68k:master 1174/1174] arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' forming offset 8 is out of the bounds [0, 7]

[Finn Thain]

On Tue, 5 Mar 2019, Andreas Schwab wrote:

> On Mar 05 2019, Finn Thain  wrote:
> 
> > interesting that the kernel's strlen implementation in 
> > include/linux/string.h can't achieve this.
> 
> This implementation is only available if ARCH_HAS_FORTIFY_SOURCE.
> 

I see. Perhaps we could add another definition to that file:

#if !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && 
defined(CONFIG_FORTIFY_SOURCE)
...
#else
__FORTIFY_INLINE __kernel_size_t strlen(const char *p)
{
return __builtin_strlen(p);
}
#endif

I didn't test that. But the following patch seems to work...

diff --git a/arch/m68k/include/asm/string.h b/arch/m68k/include/asm/string.h
index f759d944c449..3cff6b128ed3 100644
--- a/arch/m68k/include/asm/string.h
+++ b/arch/m68k/include/asm/string.h
@@ -71,4 +71,6 @@ extern void *memset(void *, int, __kernel_size_t);
 extern void *memcpy(void *, const void *, __kernel_size_t);
 #define memcpy(d, s, n) __builtin_memcpy(d, s, n)
 
+#define strlen(s) __builtin_strlen(s)
+
 #endif /* _M68K_STRING_H_ */
diff --git a/lib/string.c b/lib/string.c
index 38e4ca08e757..fe970f2160e5 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -472,6 +472,7 @@ char *strim(char *s)
 EXPORT_SYMBOL(strim);
 
 #ifndef __HAVE_ARCH_STRLEN
+#undef strlen
 /**
  * strlen - Find the length of a string
  * @s: The string to be sized

-- 

> Andreas.
> 
> 

Re: [PATCH linux-next v1 2/2] ASoC: rsnd: src: fix compiler warnings

[Kuninori Morimoto]

Hi Jiada

Thank you for your patch

> This patch moves the 'static' keyword to the front of the
> declaration to fix the compiler warnings
> 
> Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
> handling")
> Signed-off-by: Jiada Wang 
> ---

Acked-by: Kuninori Morimoto 

Re: [PATCH linux-next v1 1/2] ASoC: rsnd: src: Avoid a potential deadlock

[Kuninori Morimoto]

Hi Jiada

Thank you for your patch

> lockdep warns us that priv->lock and k->k_lock can cause a
> deadlock when after acquire of k->k_lock, process is interrupted
> by src, while in another routine of src .init, k->k_lock is
> acquired with priv->lock held.
> 
> This patch avoids a potential deadlock by not calling soc_device_match()
> in SRC .init callback, instead it adds new soc fields in priv->flags to
> differentiate SoCs.
> 
> Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
> handling")
> Signed-off-by: Jiada Wang 
> ---
(snip)
> @@ -1706,6 +1707,8 @@ static int rsnd_probe(struct platform_device *pdev)
>  
>   priv->pdev  = pdev;
>   priv->flags = (unsigned long)of_device_get_match_data(dev);
> + if (of_device_is_compatible(np, "renesas,rcar_sound-r8a77990"))
> + priv->flags |= RSND_SOC_E;
>   spin_lock_init(>lock);

Updating rsnd_of_match is nice idea
Maybe like this (not tested)


diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 9834474..e7ebc75 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -107,9 +107,12 @@
   SNDRV_PCM_FMTBIT_S24_LE)
 
 static const struct of_device_id rsnd_of_match[] = {
+   /* General Handling */
{ .compatible = "renesas,rcar_sound-gen1", .data = (void *)RSND_GEN1 },
{ .compatible = "renesas,rcar_sound-gen2", .data = (void *)RSND_GEN2 },
{ .compatible = "renesas,rcar_sound-gen3", .data = (void *)RSND_GEN3 },
+   /* Special Handling */
+   { .compatible = "renesas,rcar_sound-r8a77990", .data = (void 
*)(RSND_GEN3 | RSND_SOC_E) },
{},
 };

Re: [RFC PATCH V2 5/5] vhost: access vq metadata through kernel virtual address

[Jason Wang]

On 2019/3/7 上午12:31, Michael S. Tsirkin wrote:

+static void vhost_set_vmap_dirty(struct vhost_vmap *used)
+{
+   int i;
+
+   for (i = 0; i < used->npages; i++)
+   set_page_dirty_lock(used->pages[i]);

This seems to rely on page lock to mark page dirty.

Could it happen that page writeback will check the
page, find it clean, and then you mark it dirty and then
invalidate callback is called?




Yes. But does this break anything? The page is still there, we just 
remove a kernel mapping to it.


Thanks

[PATCH net] net: selinux: fix memory leak in selinux_netlbl_socket_post_create()

[Mao Wenan]

If netlbl_sock_setattr() is failed, it directly returns rc and forgets
to free secattr.

BUG: memory leak
unreferenced object 0x8883c3ea4200 (size 2664):
  comm "syz-executor.2", pid 8813, jiffies 4297264419 (age 156.090s)
  hex dump (first 32 bytes):
7f 00 00 01 7f 00 00 01 eb 7f ed 71 4e 24 00 00  ...qN$..
02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@
  backtrace:
[<4c0228da>] sk_alloc+0x3d/0xc00 net/core/sock.c:1523
[<535a3da2>] inet_create+0x339/0xe10 net/ipv4/af_inet.c:321
[<9aec3cfe>] __sock_create+0x3fa/0x790 net/socket.c:1275
[<4274b384>] sock_create net/socket.c:1315 [inline]
[<4274b384>] __sys_socket+0xe7/0x1d0 net/socket.c:1345
[] __do_sys_socket net/socket.c:1354 [inline]
[] __se_sys_socket net/socket.c:1352 [inline]
[] __x64_sys_socket+0x74/0xb0 net/socket.c:1352
[<4ae3186e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
[] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[] 0x

BUG: memory leak
unreferenced object 0x8883de23d570 (size 32):
  comm "syz-executor.2", pid 8813, jiffies 4297264419 (age 156.090s)
  hex dump (first 32 bytes):
02 00 00 00 00 00 00 00 60 a9 40 ce 83 88 ff ff  `.@.
01 00 00 00 03 00 00 00 10 00 00 00 00 00 00 00  
  backtrace:
[<35ba8b75>] security_sk_alloc+0x5e/0xb0 security/security.c:1473
[<302cc426>] sk_prot_alloc+0x8e/0x290 net/core/sock.c:1472
[<4c0228da>] sk_alloc+0x3d/0xc00 net/core/sock.c:1523
[<535a3da2>] inet_create+0x339/0xe10 net/ipv4/af_inet.c:321
[<9aec3cfe>] __sock_create+0x3fa/0x790 net/socket.c:1275
[<4274b384>] sock_create net/socket.c:1315 [inline]
[<4274b384>] __sys_socket+0xe7/0x1d0 net/socket.c:1345
[] __do_sys_socket net/socket.c:1354 [inline]
[] __se_sys_socket net/socket.c:1352 [inline]
[] __x64_sys_socket+0x74/0xb0 net/socket.c:1352
[<4ae3186e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
[] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[] 0x

BUG: memory leak
unreferenced object 0x8883ce40a960 (size 64):
  comm "syz-executor.2", pid 8813, jiffies 4297264420 (age 156.089s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[<29add401>] selinux_netlbl_socket_post_create+0x68/0x130 
security/selinux/netlabel.c:416
[<5368a19c>] selinux_socket_post_create+0x31a/0x7f0 
security/selinux/hooks.c:4597
[] security_socket_post_create+0x70/0xc0 
security/security.c:1385
[<671052a4>] __sock_create+0x5a6/0x790 net/socket.c:1291
[<4274b384>] sock_create net/socket.c:1315 [inline]
[<4274b384>] __sys_socket+0xe7/0x1d0 net/socket.c:1345
[] __do_sys_socket net/socket.c:1354 [inline]
[] __se_sys_socket net/socket.c:1352 [inline]
[] __x64_sys_socket+0x74/0xb0 net/socket.c:1352
[<4ae3186e>] do_syscall_64+0xc8/0x580 arch/x86/entry/common.c:290
[] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[] 0x

Fixes: 389fb800ac8b("netlabel: Label incoming TCP connections correctly in 
SELinux")
Reported-by: Hulk Robot 
Signed-off-by: Mao Wenan 
---
 security/selinux/netlabel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index 186e727b737b..f3da05338580 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -426,6 +426,9 @@ int selinux_netlbl_socket_post_create(struct sock *sk, u16 
family)
rc = 0;
break;
}
+   if (rc != 0) {
+   netlbl_secattr_free(secattr);
+   }
 
return rc;
 }
-- 
2.20.1

[RFC] udftools: steps towards fsck

[Steve Magnani]

(Please remove at least LKML when responding. Mailing lists are a 
scattershot attempt to reach others who might be interested in this 
topic since I'm not aware of any linux-udf mailing list. )


A few months ago I stumbled across an interesting bit of abandonware in 
the Sourceforge CVS repo that hosted UDF development through about 2004. 
Code that originated here eventually became the modern-day udftools:


    https://sourceforge.net/p/linux-udf/code/

The 'udf' module in that repo contains a program from 1999 named 
'chkudf', which appears to have been written by Rob Simms. Being from 
the Y2K era, the program has no awareness of anything beyond UDF2.01; in 
particular, its comprehension of VAT reflects UDF1.50 and not the 
revamped design introduced in UDF2.00. But it does have an ability to 
analyze the major UDF data structures and to walk the filesystem.


I've spent quite a bit of time enhancing and fixing bugs in this code, 
with a short term goal of being able to report damage to UDF2.01 
filesystems on "hard disk" (magnetic and SSD) media. It's not quite to 
the point of being release-ready, but I think the code is on the cusp of 
becoming useful to others so I wanted to get some feedback on the approach.


I posted a GIT port (via SVN) of the CVS repo here, including all the 
changes I've made so far:


    https://github.com/smagnani/chkudf.git

If you're interested in building the code you should be able to just run 
'make' within the chkudf folder. On Debian-derived systems you'll need 
libblkid-dev installed in order to build.


Some questions for consideration:

* Would a udffsck limited to checking of UDF2.01 and earlier on "hard 
disk" media be a sufficiently useful starting point to justify inclusion 
in udftools? Obviously a tool with such limitations would have to be 
particularly vigilant about ensuring that media-under-test doesn't 
exceed its capabilities.


* If so, do you think the chkudf implementation could qualify? It's not 
ready yet, but with an investment of some time and energy it could be 
made more functionally complete and (maybe more importantly) more 
user-friendly.


In part this is a question of whether the chkudf design can support 
enhancements to get (eventually) to UDF2.60 and optical media support, 
balanced against the many years without an open-source udffsck and not 
"letting the perfect become the enemy of the good."


* For any standards-based parser it's important to have examples of as 
many variations as possible (both normal and pathological) in order to 
ensure that corner cases and less common features are tested properly. 
Can anyone point me to any good sources of UDF data for testing? There 
are always commercial DVDs and Blu-Ray discs, of course, and I've 
cobbled together a few special cases by hand (i.e., a filesystem with 
directory cycles), but I have no examples with extended attributes or 
stream data. If I could find a DVD of Mac software in a resale shop 
would that help? [Side note, I've thought of enhancing chkudf to support 
a tool that would store all the UDF structures of a filesystem in a 
tarball that could be used to reconstitute that filesystem within a 
sparse file. Since none of the file contents would be stored the 
tarballs would be relatively small even if they represent terabyte-scale 
filesystems.


* Are there versions (or features) of UDF that are less important to 
support than others (1.50? Strategy 4096? Named streams? etc.) I know 
1.02, 2.01, and 2.50 are in wide use.


* What kinds of repairs are most important to implement? I was thinking 
that regeneration of the Logical Volume Integrity Descriptor and the 
unallocated space bitmap are both important and hopefully relatively 
straightforward. Beyond that...recovering ICBs to "lost+found"?



My 2 cents:
I didn't write this program. There are things I would have done 
differently, but to this point I have tried to work within the existing 
design and code style. After becoming more aware of differences between 
the various UDF standards (in particular, the increase in complexity 
since 2.01) and the many errata involved, I have a gut feeling that an 
implementation in a language that supports inheritance might be a lot 
more manageable over the long term - but it's not something I've spent a 
lot of time thinking about. I've only recently become aware of 
UDFclient, and haven't had time to look over its design yet. And, I can 
see the potential for followon utilities such as a filesystem resizer - 
which might argue for making more of the code library-based and not so 
heavy on printed output.


Bottom line...udffsck has to start somewhere, could it start with chkudf?

Thanks for reading.

 Steven J. Magnani   "I claim this network for MARS!
 www.digidescorp.com  Earthling, return my space modulator!"

 #include 

Re: [PATCH V1 07/11] mmc: cqhci: add quirk for setting DCMD CMD_TIMING

[Ritesh Harjani]

On 3/6/2019 6:30 PM, Adrian Hunter wrote:

On 2/03/19 7:20 AM, Sowjanya Komatineni wrote:

This patch adds a quirk for setting CMD_TIMING to 1 in descriptor
for DCMD with R1B response type to allow the command to be sent to
device during data activity or busy time.

Tegra186 CQHCI host has bug where it selects DATA_PRESENT_SELECT
to 1 by CQHCI controller for DCMDs with R1B response type and
since DCMD does not trigger any data transfer, DCMD task complete
happens leaving the DATA FSM of host controller in wait state for
data.

This effects the data transfer task issued after R1B DCMD task
and no interrupt is generated for the data transfer task.

SW WAR for this issue is to set CMD_TIMING bit to 1 in DCMD task
descriptor and as DCMD task descriptor preparation is done by
cqhci driver, this patch adds cqequirk to handle this.

Signed-off-by: Sowjanya Komatineni 
---
  drivers/mmc/host/cqhci.c | 5 -
  drivers/mmc/host/cqhci.h | 1 +
  2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
index a8af682a9182..b34c07125f32 100644
--- a/drivers/mmc/host/cqhci.c
+++ b/drivers/mmc/host/cqhci.c
@@ -521,7 +521,10 @@ static void cqhci_prep_dcmd_desc(struct mmc_host *mmc,
} else {
if (mrq->cmd->flags & MMC_RSP_R1B) {
resp_type = 0x3;
-   timing = 0x0;
+   if (cq_host->quirks & CQHCI_QUIRK_CMD_TIMING_R1B_DCMD)
+   timing = 0x1;
+   else
+   timing = 0x0;

I was thinking it would be nice if there was a generic way for drivers to
make changes to descriptors before a task is started.  Currently there is
host->ops->write_l() which would make it possible by checking for CQHCI_TDBR
register and, in this case, the DCMD tag.  We would need to export
get_desc(), perhaps rename it cqhci_get_desc() and put it in cqhci.h since
it is an inline function.


We take spin_lock_irqsave after the descriptor is prepared and before 
writing to TDBR.
Not sure but tomorrow this may become a limitation for drivers to make 
changes to

descriptors if they edit descriptors in host->ops->write_l() call.
Though in this case it is not required here.



Alternatively we could add host->ops for descriptor preparation.


Both ways sounds good to me.
But maybe adding a host->ops for descriptor preparation is better way to go,
since that will be the right interface exposed to make changes to 
descriptors.




What do people think?


} else {
resp_type = 0x2;
timing = 0x1;
diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h
index 9e68286a07b4..f96d8565cc07 100644
--- a/drivers/mmc/host/cqhci.h
+++ b/drivers/mmc/host/cqhci.h
@@ -170,6 +170,7 @@ struct cqhci_host {
  
  	u32 quirks;

  #define CQHCI_QUIRK_SHORT_TXFR_DESC_SZ0x1
+#define CQHCI_QUIRK_CMD_TIMING_R1B_DCMD0x2
  
  	bool enabled;

bool halted;

Re: [RFC PATCH V2 4/5] vhost: introduce helpers to get the size of metadata area

[Jason Wang]

On 2019/3/7 上午2:43, Souptick Joarder wrote:

On Wed, Mar 6, 2019 at 12:48 PM Jason Wang  wrote:

Signed-off-by: Jason Wang 

Is the change log left with any particular reason ?



Nope, will add the log.

Thanks



---
  drivers/vhost/vhost.c | 46 --
  1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2025543..1015464 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -413,6 +413,27 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
 vhost_vq_free_iovecs(dev->vqs[i]);
  }

+static size_t vhost_get_avail_size(struct vhost_virtqueue *vq, int num)
+{
+   size_t event = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
+
+   return sizeof(*vq->avail) +
+  sizeof(*vq->avail->ring) * num + event;
+}
+
+static size_t vhost_get_used_size(struct vhost_virtqueue *vq, int num)
+{
+   size_t event = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
+
+   return sizeof(*vq->used) +
+  sizeof(*vq->used->ring) * num + event;
+}
+
+static size_t vhost_get_desc_size(struct vhost_virtqueue *vq, int num)
+{
+   return sizeof(*vq->desc) * num;
+}
+
  void vhost_dev_init(struct vhost_dev *dev,
 struct vhost_virtqueue **vqs, int nvqs, int iov_limit)
  {
@@ -1253,13 +1274,9 @@ static bool vq_access_ok(struct vhost_virtqueue *vq, 
unsigned int num,
  struct vring_used __user *used)

  {
-   size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
-
-   return access_ok(desc, num * sizeof *desc) &&
-  access_ok(avail,
-sizeof *avail + num * sizeof *avail->ring + s) &&
-  access_ok(used,
-   sizeof *used + num * sizeof *used->ring + s);
+   return access_ok(desc, vhost_get_desc_size(vq, num)) &&
+  access_ok(avail, vhost_get_avail_size(vq, num)) &&
+  access_ok(used, vhost_get_used_size(vq, num));
  }

  static void vhost_vq_meta_update(struct vhost_virtqueue *vq,
@@ -1311,22 +1328,18 @@ static bool iotlb_access_ok(struct vhost_virtqueue *vq,

  int vq_meta_prefetch(struct vhost_virtqueue *vq)
  {
-   size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
 unsigned int num = vq->num;

 if (!vq->iotlb)
 return 1;

 return iotlb_access_ok(vq, VHOST_ACCESS_RO, (u64)(uintptr_t)vq->desc,
-  num * sizeof(*vq->desc), VHOST_ADDR_DESC) &&
+  vhost_get_desc_size(vq, num), VHOST_ADDR_DESC) &&
iotlb_access_ok(vq, VHOST_ACCESS_RO, (u64)(uintptr_t)vq->avail,
-  sizeof *vq->avail +
-  num * sizeof(*vq->avail->ring) + s,
+  vhost_get_avail_size(vq, num),
VHOST_ADDR_AVAIL) &&
iotlb_access_ok(vq, VHOST_ACCESS_WO, (u64)(uintptr_t)vq->used,
-  sizeof *vq->used +
-  num * sizeof(*vq->used->ring) + s,
-  VHOST_ADDR_USED);
+  vhost_get_used_size(vq, num), VHOST_ADDR_USED);
  }
  EXPORT_SYMBOL_GPL(vq_meta_prefetch);

@@ -1343,13 +1356,10 @@ bool vhost_log_access_ok(struct vhost_dev *dev)
  static bool vq_log_access_ok(struct vhost_virtqueue *vq,
  void __user *log_base)
  {
-   size_t s = vhost_has_feature(vq, VIRTIO_RING_F_EVENT_IDX) ? 2 : 0;
-
 return vq_memory_access_ok(log_base, vq->umem,
vhost_has_feature(vq, VHOST_F_LOG_ALL)) &&
 (!vq->log_used || log_access_ok(log_base, vq->log_addr,
-   sizeof *vq->used +
-   vq->num * sizeof *vq->used->ring + s));
+ vhost_get_used_size(vq, vq->num)));
  }

  /* Can we start vq? */
--
1.8.3.1

Re: [RFC PATCH V2 4/5] vhost: introduce helpers to get the size of metadata area

[Jason Wang]

On 2019/3/6 下午6:56, Christophe de Dinechin wrote:

On 6 Mar 2019, at 08:18, Jason Wang  wrote:

Signed-off-by: Jason Wang
---
drivers/vhost/vhost.c | 46 --
1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2025543..1015464 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -413,6 +413,27 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
vhost_vq_free_iovecs(dev->vqs[i]);
}

+static size_t vhost_get_avail_size(struct vhost_virtqueue *vq, int num)

Nit: Any reason not to make `num` unsigned or size_t?



Let me use unsigned int to match the definition of vq->num.

Thanks

Re: [RFC PATCH V2 2/5] vhost: fine grain userspace memory accessors

[Jason Wang]

On 2019/3/6 下午6:45, Christophe de Dinechin wrote:



On 6 Mar 2019, at 08:18, Jason Wang  wrote:

This is used to hide the metadata address from virtqueue helpers. This
will allow to implement a vmap based fast accessing to metadata.

Signed-off-by: Jason Wang 
---
drivers/vhost/vhost.c | 94 +--
1 file changed, 77 insertions(+), 17 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 400aa78..29709e7 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -869,6 +869,34 @@ static inline void __user *__vhost_get_user(struct 
vhost_virtqueue *vq,
ret; \
})

+static inline int vhost_put_avail_event(struct vhost_virtqueue *vq)
+{
+   return vhost_put_user(vq, cpu_to_vhost16(vq, vq->avail_idx),
+ vhost_avail_event(vq));
+}
+
+static inline int vhost_put_used(struct vhost_virtqueue *vq,
+struct vring_used_elem *head, int idx,
+int count)
+{
+   return vhost_copy_to_user(vq, vq->used->ring + idx, head,
+ count * sizeof(*head));
+}
+
+static inline int vhost_put_used_flags(struct vhost_virtqueue *vq)
+
+{
+   return vhost_put_user(vq, cpu_to_vhost16(vq, vq->used_flags),
+ >used->flags);
+}
+
+static inline int vhost_put_used_idx(struct vhost_virtqueue *vq)
+
+{
+   return vhost_put_user(vq, cpu_to_vhost16(vq, vq->last_used_idx),
+ >used->idx);
+}
+
#define vhost_get_user(vq, x, ptr, type)\
({ \
int ret; \
@@ -907,6 +935,43 @@ static void vhost_dev_unlock_vqs(struct vhost_dev *d)
mutex_unlock(>vqs[i]->mutex);
}

+static inline int vhost_get_avail_idx(struct vhost_virtqueue *vq,
+ __virtio16 *idx)
+{
+   return vhost_get_avail(vq, *idx, >avail->idx);
+}
+
+static inline int vhost_get_avail_head(struct vhost_virtqueue *vq,
+  __virtio16 *head, int idx)
+{
+   return vhost_get_avail(vq, *head,
+  >avail->ring[idx & (vq->num - 1)]);
+}
+
+static inline int vhost_get_avail_flags(struct vhost_virtqueue *vq,
+   __virtio16 *flags)
+{
+   return vhost_get_avail(vq, *flags, >avail->flags);
+}
+
+static inline int vhost_get_used_event(struct vhost_virtqueue *vq,
+  __virtio16 *event)
+{
+   return vhost_get_avail(vq, *event, vhost_used_event(vq));
+}
+
+static inline int vhost_get_used_idx(struct vhost_virtqueue *vq,
+__virtio16 *idx)
+{
+   return vhost_get_used(vq, *idx, >used->idx);
+}
+
+static inline int vhost_get_desc(struct vhost_virtqueue *vq,
+struct vring_desc *desc, int idx)
+{
+   return vhost_copy_from_user(vq, desc, vq->desc + idx, sizeof(*desc));
+}
+
static int vhost_new_umem_range(struct vhost_umem *umem,
u64 start, u64 size, u64 end,
u64 userspace_addr, int perm)
@@ -1840,8 +1905,7 @@ int vhost_log_write(struct vhost_virtqueue *vq, struct 
vhost_log *log,
static int vhost_update_used_flags(struct vhost_virtqueue *vq)
{
void __user *used;
-   if (vhost_put_user(vq, cpu_to_vhost16(vq, vq->used_flags),
-  >used->flags) < 0)
+   if (vhost_put_used_flags(vq))
return -EFAULT;
if (unlikely(vq->log_used)) {
/* Make sure the flag is seen before log. */
@@ -1858,8 +1922,7 @@ static int vhost_update_used_flags(struct vhost_virtqueue 
*vq)

static int vhost_update_avail_event(struct vhost_virtqueue *vq, u16 avail_event)
{
-   if (vhost_put_user(vq, cpu_to_vhost16(vq, vq->avail_idx),
-  vhost_avail_event(vq)))
+   if (vhost_put_avail_event(vq))
return -EFAULT;
if (unlikely(vq->log_used)) {
void __user *used;
@@ -1895,7 +1958,7 @@ int vhost_vq_init_access(struct vhost_virtqueue *vq)
r = -EFAULT;
goto err;
}
-   r = vhost_get_used(vq, last_used_idx, >used->idx);
+   r = vhost_get_used_idx(vq, _used_idx);
if (r) {
vq_err(vq, "Can't access used idx at %p\n",
   >used->idx);

 From the error case, it looks like you are not entirely encapsulating
knowledge of what the accessor uses, i.e. it’s not:

vq_err(vq, "Can't access used idx at %p\n",
   _user_idx);

Maybe move error message within accessor?



Good catch. Will fix but I still prefer to keep the place of vq_err(). 
Moving error message (if needed) could be done in the future.


Thanks





@@ -2094,7 +2157,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq,
last_avail_idx = vq->last_avail_idx;

if (vq->avail_idx == 

[PATCH linux-next v1 1/2] ASoC: rsnd: src: Avoid a potential deadlock

[Jiada Wang]

lockdep warns us that priv->lock and k->k_lock can cause a
deadlock when after acquire of k->k_lock, process is interrupted
by src, while in another routine of src .init, k->k_lock is
acquired with priv->lock held.

This patch avoids a potential deadlock by not calling soc_device_match()
in SRC .init callback, instead it adds new soc fields in priv->flags to
differentiate SoCs.

Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
handling")
Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/core.c | 3 +++
 sound/soc/sh/rcar/rsnd.h | 5 +
 sound/soc/sh/rcar/src.c  | 9 +
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c
index 022996d2db13..c2d466fe191f 100644
--- a/sound/soc/sh/rcar/core.c
+++ b/sound/soc/sh/rcar/core.c
@@ -1680,6 +1680,7 @@ static int rsnd_rdai_continuance_probe(struct rsnd_priv 
*priv,
 static int rsnd_probe(struct platform_device *pdev)
 {
struct rsnd_priv *priv;
+   struct device_node *np = pdev->dev.of_node;
struct device *dev = >dev;
struct rsnd_dai *rdai;
int (*probe_func[])(struct rsnd_priv *priv) = {
@@ -1706,6 +1707,8 @@ static int rsnd_probe(struct platform_device *pdev)
 
priv->pdev  = pdev;
priv->flags = (unsigned long)of_device_get_match_data(dev);
+   if (of_device_is_compatible(np, "renesas,rcar_sound-r8a77990"))
+   priv->flags |= RSND_SOC_E;
spin_lock_init(>lock);
 
/*
diff --git a/sound/soc/sh/rcar/rsnd.h b/sound/soc/sh/rcar/rsnd.h
index 90625c57847b..0e6ef4e18400 100644
--- a/sound/soc/sh/rcar/rsnd.h
+++ b/sound/soc/sh/rcar/rsnd.h
@@ -607,6 +607,8 @@ struct rsnd_priv {
 #define RSND_GEN1  (1 << 0)
 #define RSND_GEN2  (2 << 0)
 #define RSND_GEN3  (3 << 0)
+#define RSND_SOC_MASK  (0xFF << 4)
+#define RSND_SOC_E (1 << 4) /* E1/E2/E3 */
 
/*
 * below value will be filled on rsnd_gen_probe()
@@ -679,6 +681,9 @@ struct rsnd_priv {
 #define rsnd_is_gen1(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN1)
 #define rsnd_is_gen2(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN2)
 #define rsnd_is_gen3(priv) (((priv)->flags & RSND_GEN_MASK) == RSND_GEN3)
+#define rsnd_is_e3(priv)   (((priv)->flags & \
+   (RSND_GEN_MASK | RSND_SOC_MASK)) == \
+   (RSND_GEN3 | RSND_SOC_E))
 
 #define rsnd_flags_has(p, f) ((p)->flags & (f))
 #define rsnd_flags_set(p, f) ((p)->flags |= (f))
diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index db81e066b92e..45096a66c074 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -14,7 +14,6 @@
  */
 
 #include "rsnd.h"
-#include 
 
 #define SRC_NAME "src"
 
@@ -189,18 +188,12 @@ const static u32 chan22[] = {
0x0006, /* 1 to 2 */
 };
 
-static const struct soc_device_attribute ov_soc[] = {
-   { .soc_id = "r8a77990" }, /* E3 */
-   { /* sentinel */ }
-};
-
 static void rsnd_src_set_convert_rate(struct rsnd_dai_stream *io,
  struct rsnd_mod *mod)
 {
struct rsnd_priv *priv = rsnd_mod_to_priv(mod);
struct device *dev = rsnd_priv_to_dev(priv);
struct snd_pcm_runtime *runtime = rsnd_io_to_runtime(io);
-   const struct soc_device_attribute *soc = soc_device_match(ov_soc);
int is_play = rsnd_io_is_play(io);
int use_src = 0;
u32 fin, fout;
@@ -307,7 +300,7 @@ static void rsnd_src_set_convert_rate(struct 
rsnd_dai_stream *io,
/*
 * E3 need to overwrite
 */
-   if (soc)
+   if (rsnd_is_e3(priv))
switch (rsnd_mod_id(mod)) {
case 0:
case 4:
-- 
2.19.2

[PATCH linux-next v1 2/2] ASoC: rsnd: src: fix compiler warnings

[Jiada Wang]

compiler complains about following declarations

sound/soc/sh/rcar/src.c:174:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsdsr_table_pattern1[] = {
 ^
sound/soc/sh/rcar/src.c:183:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsdsr_table_pattern2[] = {
 ^
sound/soc/sh/rcar/src.c:192:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 bsisr_table[] = {
 ^
sound/soc/sh/rcar/src.c:201:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan28[] = {
 ^
sound/soc/sh/rcar/src.c:210:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan244888[] = {
 ^
sound/soc/sh/rcar/src.c:219:1: warning: 'static' is not at beginning of 
declaration [-Wold-style-declaration]
 const static u32 chan22[] = {
 ^

This patch moves the 'static' keyword to the front of the
declaration to fix the compiler warnings

Fixes: linux-next commit 7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR 
handling")
Signed-off-by: Jiada Wang 
---
 sound/soc/sh/rcar/src.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/sound/soc/sh/rcar/src.c b/sound/soc/sh/rcar/src.c
index 45096a66c074..585ffba0244b 100644
--- a/sound/soc/sh/rcar/src.c
+++ b/sound/soc/sh/rcar/src.c
@@ -134,7 +134,7 @@ unsigned int rsnd_src_get_rate(struct rsnd_priv *priv,
return rate;
 }
 
-const static u32 bsdsr_table_pattern1[] = {
+static const u32 bsdsr_table_pattern1[] = {
0x0180, /* 6 - 1/6 */
0x0100, /* 6 - 1/4 */
0x00c0, /* 6 - 1/3 */
@@ -143,7 +143,7 @@ const static u32 bsdsr_table_pattern1[] = {
0x0040, /* 6 - 1   */
 };
 
-const static u32 bsdsr_table_pattern2[] = {
+static const u32 bsdsr_table_pattern2[] = {
0x0240, /* 6 - 1/6 */
0x0180, /* 6 - 1/4 */
0x0120, /* 6 - 1/3 */
@@ -152,7 +152,7 @@ const static u32 bsdsr_table_pattern2[] = {
0x0060, /* 6 - 1   */
 };
 
-const static u32 bsisr_table[] = {
+static const u32 bsisr_table[] = {
0x00100060, /* 6 - 1/6 */
0x00100040, /* 6 - 1/4 */
0x00100030, /* 6 - 1/3 */
@@ -161,7 +161,7 @@ const static u32 bsisr_table[] = {
0x00100020, /* 6 - 1   */
 };
 
-const static u32 chan28[] = {
+static const u32 chan28[] = {
0x0006, /* 1 to 2 */
0x01fe, /* 1 to 8 */
0x01fe, /* 1 to 8 */
@@ -170,7 +170,7 @@ const static u32 chan28[] = {
0x01fe, /* 1 to 8 */
 };
 
-const static u32 chan244888[] = {
+static const u32 chan244888[] = {
0x0006, /* 1 to 2 */
0x001e, /* 1 to 4 */
0x001e, /* 1 to 4 */
@@ -179,7 +179,7 @@ const static u32 chan244888[] = {
0x01fe, /* 1 to 8 */
 };
 
-const static u32 chan22[] = {
+static const u32 chan22[] = {
0x0006, /* 1 to 2 */
0x0006, /* 1 to 2 */
0x0006, /* 1 to 2 */
-- 
2.19.2

[PATCH linux-next v1 0/2] misc fix in src.c

[Jiada Wang]

two issues were found due to linux-next commit
7674bec4fc09 ("ASoC: rsnd: update BSDSR/BSDISR handling")
this patch-set address these two issues

Jiada Wang (2):
  ASoC: rsnd: src: Avoid a potential deadlock
  ASoC: rsnd: src: fix compiler warnings

 sound/soc/sh/rcar/core.c |  3 +++
 sound/soc/sh/rcar/rsnd.h |  5 +
 sound/soc/sh/rcar/src.c  | 21 +++--
 3 files changed, 15 insertions(+), 14 deletions(-)

-- 
2.19.2

git-send-patch v2

[Enrico Weigelt, metux IT consult]

Here's v2 of my little helper for sending patches to maintainers.

changes v2:
- don't check for topdir 'firmware', which had been removed recently


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

[PATCH v2] scripts: helper for mailing patches from git to the maintainers

[Enrico Weigelt, metux IT consult]

This is a little helper script for mailing patches out of a git
branch to the corresponding maintainers.

Essentially, it scans the touched files, asks get_maintainer.pl
for their maintainers and calls git-send-email for mailing out
the patches.

Syntax:

  ./scripts/git-send-patch  []

Examples:

  ./scripts/git-send-patch HEAD^
  ./scripts/git-send-patch linus/master --dry-run

Signed-off-by: Enrico Weigelt, metux IT consult 
---
 scripts/git-send-patch | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100755 scripts/git-send-patch

diff --git a/scripts/git-send-patch b/scripts/git-send-patch
new file mode 100755
index 000..b54790f
--- /dev/null
+++ b/scripts/git-send-patch
@@ -0,0 +1,62 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+[ -x "$GIT" ]   || export GIT=git
+[ -d "$KERNELSRC" ] || export KERNELSRC=.
+
+LKML="linux-kernel@vger.kernel.org"
+
+check_ksrc() {
+if [ -d $KERNELSRC/arch ] && \
+   [ -d $KERNELSRC/block ] && \
+   [ -d $KERNELSRC/init ] && \
+   [ -d $KERNELSRC/kernel ] && \
+   [ -d $KERNELSRC/sound ] && \
+   [ -d $KERNELSRC/drivers ] && \
+   [ -d $KERNELSRC/net ] && \
+   [ -d $KERNELSRC/include ] && \
+   [ -f $KERNELSRC/COPYING ] && \
+   [ -f $KERNELSRC/MAINTAINERS ] && \
+   [ -f $KERNELSRC/CREDITS ] && \
+   [ -f $KERNELSRC/Kconfig ] && \
+   [ -f $KERNELSRC/Makefile ]; then
+return 0
+else
+echo "$0: cant find the kernel source tree. please call me from the 
topdir" >&2
+exit 1
+fi
+}
+
+check_ksrc
+
+get_files() {
+$GIT diff --name-only "$REF"
+}
+
+get_maintainers() {
+$KERNELSRC/scripts/get_maintainer.pl --m --l --remove-duplicates 
`get_files` |
+grep -v "$LKML" | \
+grep -E "(maintainer|reviewer|open list)" | \
+grep -o '[[:alnum:]+\.\_\-]*@[[:alnum:]+\.\_\-]*'
+}
+
+construct_params() {
+echo -n "--to=$LKML "
+for a in `get_maintainers`; do
+echo -n "--cc=$a "
+done
+}
+
+if [ ! "$1" ]; then
+echo "$0: missing git revision to send out" >&2
+echo "" >&2
+echo "for example: 'HEAD^' for sending just the last patch" >&2
+echo >&2
+echo "$0  []"
+exit 1
+fi
+
+REF="$1"
+shift
+
+$GIT send-email `construct_params` "$REF" "$@"
-- 
1.9.1

[GIT PULL] leaking_addresses: changes for v5.1-rc1

[Tobin C. Harding]

Hi Linus,

Please consider pulling changes to scripts/leaking_addresses.pl

I've started using my kernel.org email address.  I believe its the key
you care about not the email address this email is sent from, the tag is
signed as usual.

thanks,
Tobin.


The following changes since commit 1c163f4c7b3f621efff9b28a47abb36f7378d783:

  Linux 5.0 (2019-03-03 15:21:29 -0800)

are available in the Git repository at:

  ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/tobin/leaks.git 
tags/leaks-5.1-rc1

for you to fetch changes up to 9ac060a708e054233265f8febfcef009ac3da826:

  leaking_addresses: Completely remove --version flag (2019-03-07 08:53:18 
+1100)


leaking_addresses patches for 5.1-rc1

Here are two super trivial patches to the leaking addresses script for
the 5.1-rc1 merge window.  One fixes the debugging output which is
currently broken in a bunch of places, the other removes the --version
command line option.

Both patches have been tested and sitting in linux-next tree for a month
or so.

Signed-off-by: Tobin C. Harding 


Tobin C. Harding (2):
  leaking_addresses: Fix calls to dprint
  leaking_addresses: Completely remove --version flag

 scripts/leaking_addresses.pl | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

[PATCH v2] appletalk: Correctly check return value of register_snap_client

[Yue Haibing]

From: YueHaibing 

register_snap_client may return NULL, all the callers
check it, but only print a warning. This will result in
NULL pointer dereference in unregister_snap_client and other
places.

It has always been used like this since v2.6

Reported-by: Dan Carpenter 
Signed-off-by: YueHaibing 
---
v2: fix aarp_dl leak
---
 include/linux/atalk.h |  2 +-
 net/appletalk/aarp.c  | 13 ++---
 net/appletalk/ddp.c   | 20 
 3 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/include/linux/atalk.h b/include/linux/atalk.h
index 5a90f28..0e5265a 100644
--- a/include/linux/atalk.h
+++ b/include/linux/atalk.h
@@ -108,7 +108,7 @@ static __inline__ struct elapaarp *aarp_hdr(struct sk_buff 
*skb)
 #define AARP_RESOLVE_TIME  (10 * HZ)
 
 extern struct datalink_proto *ddp_dl, *aarp_dl;
-extern void aarp_proto_init(void);
+extern int aarp_proto_init(void);
 
 /* Inter module exports */
 
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 49a16ce..d11372d 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -879,15 +879,22 @@ static struct notifier_block aarp_notifier = {
 
 static unsigned char aarp_snap_id[] = { 0x00, 0x00, 0x00, 0x80, 0xF3 };
 
-void __init aarp_proto_init(void)
+int __init aarp_proto_init(void)
 {
+   int rc;
+
aarp_dl = register_snap_client(aarp_snap_id, aarp_rcv);
-   if (!aarp_dl)
+   if (!aarp_dl) {
printk(KERN_CRIT "Unable to register AARP with SNAP.\n");
+   return -ENOMEM;
+   }
timer_setup(_timer, aarp_expire_timeout, 0);
aarp_timer.expires  = jiffies + sysctl_aarp_expiry_time;
add_timer(_timer);
-   register_netdevice_notifier(_notifier);
+   rc = register_netdevice_notifier(_notifier);
+   if (rc)
+   unregister_snap_client(aarp_dl);
+   return rc;
 }
 
 /* Remove the AARP entries associated with a device. */
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c
index 795fbc6..709d254 100644
--- a/net/appletalk/ddp.c
+++ b/net/appletalk/ddp.c
@@ -1904,9 +1904,6 @@ static unsigned char ddp_snap_id[] = { 0x08, 0x00, 0x07, 
0x80, 0x9B };
 EXPORT_SYMBOL(atrtr_get_dev);
 EXPORT_SYMBOL(atalk_find_dev_addr);
 
-static const char atalk_err_snap[] __initconst =
-   KERN_CRIT "Unable to register DDP with SNAP.\n";
-
 /* Called by proto.c on kernel start up */
 static int __init atalk_init(void)
 {
@@ -1921,17 +1918,22 @@ static int __init atalk_init(void)
goto out_proto;
 
ddp_dl = register_snap_client(ddp_snap_id, atalk_rcv);
-   if (!ddp_dl)
-   printk(atalk_err_snap);
+   if (!ddp_dl) {
+   pr_crit("Unable to register DDP with SNAP.\n");
+   goto out_sock;
+   }
 
dev_add_pack(_packet_type);
dev_add_pack(_packet_type);
 
rc = register_netdevice_notifier(_notifier);
if (rc)
-   goto out_sock;
+   goto out_snap;
+
+   rc = aarp_proto_init();
+   if (rc)
+   goto out_dev;
 
-   aarp_proto_init();
rc = atalk_proc_init();
if (rc)
goto out_aarp;
@@ -1945,11 +1947,13 @@ static int __init atalk_init(void)
atalk_proc_exit();
 out_aarp:
aarp_cleanup_module();
+out_dev:
unregister_netdevice_notifier(_notifier);
-out_sock:
+out_snap:
dev_remove_pack(_packet_type);
dev_remove_pack(_packet_type);
unregister_snap_client(ddp_dl);
+out_sock:
sock_unregister(PF_APPLETALK);
 out_proto:
proto_unregister(_proto);
-- 
2.7.0

[PATCH v2] drivers: uio: Kconfig: pedantic formatting

[Enrico Weigelt, metux IT consult]

Formatting of Kconfig doesn't look so pretty, so just take
a damp cloth and clean it up.

Signed-off-by: Enrico Weigelt, metux IT consult 
---
 drivers/uio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 7e8dc78..4286b73 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -17,7 +17,7 @@ config UIO_CIF
depends on PCI
help
  Driver for Hilscher CIF DeviceNet and Profibus cards.  This
- driver requires a userspace component called cif that handles
+ driver requires a userspace component called cif that handles
  all of the heavy lifting and can be found at:

 
-- 
1.9.1

Re: [PATCH v2 03/10] dt-binding: gce: add binding for gce subsys property

[CK Hu]

Hi, Bibby:

On Thu, 2019-03-07 at 09:39 +0800, CK Hu wrote:
> Hi, Bibby:
> 
> On Wed, 2019-03-06 at 17:50 +0800, Bibby Hsieh wrote:
> > cmdq driver provide a function that get the relationship
> > of sub system number from device node for client.
> > add specification for #subsys-cells, mediatek,gce-subsys.
> > 
> > Signed-off-by: Bibby Hsieh 
> > ---
> >  Documentation/devicetree/bindings/mailbox/mtk-gce.txt | 11 ++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt 
> > b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > index 812698f..07b2adf 100644
> > --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> > @@ -26,6 +26,13 @@ Required properties:
> > phandle: Label name of a gce node.
> > event_number: the event number defined in 'dt-bindings/gce/mt8173-gce.h'
> >   or 'dt-binding/gce/mt8183-gce.h'.
> > +#subsys-cells: Should be 2.
> > +   < register_base_address subsys_number>
> > +   phandle: Label name of a gce node.
> > +   register_base_address: the register base address that client
> > +  want to write or read.
> 
> This look like the same as 'reg' property. I would prefer use
> already-defined property, for example:
> 
>   mmsys: clock-controller@1400 {
>   compatible = "mediatek,mt8173-mmsys", "syscon";
>   reg = <0 0x1400 0 0x1000>;
>   mediatek,gce-subsys = < SUBSYS_1400>;
>   };

My previous thinking may not be proper, GCE could write register but its
behavior may be not the same as CPU, so it's better not to mix these two
register_base_address.

Regards,
CK

> 
> Regards,
> CK
> 
> > +   subsys_number: specify the sub-system id which is corresponding
> > +  to the register address.
> >  
> >  Required properties for a client device:
> >  - mboxes: Client use mailbox to communicate with GCE, it should have this
> > @@ -50,6 +57,7 @@ Example:
> > thread-num = CMDQ_THR_MAX_COUNT;
> > #mbox-cells = <3>;
> > #event-cells = <1>;
> > +   #subsys-cells = <2>;
> > };
> >  
> >  Example for a client device:
> > @@ -58,7 +66,8 @@ Example for a client device:
> > compatible = "mediatek,mt8173-mmsys";
> > mboxes = < 0 CMDQ_THR_PRIO_LOWEST 1>,
> >  < 1 CMDQ_THR_PRIO_LOWEST 1>;
> > -   mediatek,gce-subsys = ;
> > +   mediatek,gce-subsys = < 0x1400 SUBSYS_1400>,
> > + < 0x1401 SUBSYS_1401>;
> > mediatek,gce-event-names = "rdma0_sof",
> >"rsz0_sof";
> > mediatek,gce-events = < CMDQ_EVENT_MDP_RDMA0_SOF>,
> 

Re: [PATCH 1/2] Bluetooth: hci_qca: Rename STATE_ to QCA_

[Balakrishna Godavarthi]

On 2019-03-07 06:10, Matthias Kaehlcke wrote:

Rename STATE_IN_BAND_SLEEP_ENABLED to QCA_IN_BAND_SLEEP_ENABLED.
The constant represents a flag (multiple flags can be set at once),
not a unique state of the controller or driver. Also use the BIT()
macro to specify the position of the flag instead of an integer
literal.

Signed-off-by: Matthias Kaehlcke 
---
 drivers/bluetooth/hci_qca.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 237aea34b69f1..ab8e59419dbc4 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -54,8 +54,7 @@
 #define HCI_IBS_WAKE_ACK   0xFC
 #define HCI_MAX_IBS_SIZE   10

-/* Controller states */
-#define STATE_IN_BAND_SLEEP_ENABLED1
+#define QCA_IN_BAND_SLEEP_ENABLED  BIT(0)

 #define IBS_WAKE_RETRANS_TIMEOUT_MS100
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
@@ -775,7 +774,7 @@ static int qca_enqueue(struct hci_uart *hu, struct
sk_buff *skb)
/* Don't go to sleep in middle of patch download or
 * Out-Of-Band(GPIOs control) sleep is selected.
 */
-   if (!test_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags)) {
+   if (!test_bit(QCA_IN_BAND_SLEEP_ENABLED, >flags)) {
skb_queue_tail(>txq, skb);
spin_unlock_irqrestore(>hci_ibs_lock, flags);
return 0;
@@ -1192,7 +1191,7 @@ static int qca_setup(struct hci_uart *hu)
return ret;

/* Patch downloading has to be done without IBS mode */
-   clear_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
+   clear_bit(QCA_IN_BAND_SLEEP_ENABLED, >flags);

if (qcadev->btsoc_type == QCA_WCN3990) {
bt_dev_info(hdev, "setting up wcn3990");
@@ -1236,7 +1235,7 @@ static int qca_setup(struct hci_uart *hu)
/* Setup patch / NVM configurations */
 	ret = qca_uart_setup(hdev, qca_baudrate, qcadev->btsoc_type, 
soc_ver);

if (!ret) {
-   set_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
+   set_bit(QCA_IN_BAND_SLEEP_ENABLED, >flags);
qca_debugfs_init(hdev);
} else if (ret == -ENOENT) {
/* No patch/nvm-config found, run with original fw/config */
@@ -1294,7 +1293,7 @@ static void qca_power_shutdown(struct hci_uart 
*hu)

 * data in skb's.
 */
spin_lock_irqsave(>hci_ibs_lock, flags);
-   clear_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
+   clear_bit(QCA_IN_BAND_SLEEP_ENABLED, >flags);
qca_flush(hu);
spin_unlock_irqrestore(>hci_ibs_lock, flags);



Reviewed-by: Balakrishna Godavarthi 
--
Regards
Balakrishna.

Dear Friend,

[Mrs Clara David]

--
Dear Friend,

I am Mrs Clara David. am sending you this brief letter to solicit your
partnership to transfer $18.5 million US Dollars.I shall send you more
information and procedures when I receive positive response from you.
please send me a message in my Email box (mrsclarad...@gmail.com)
as i wait to hear from you.

Best regard
Mrs Clara David.
--