[PATCH] arch/x86: Initialize __max_smt_threads to 1

2017-12-06 Thread Prarit Bhargava 
A single socket, single core, single thread system has __max_smt_threads
set to 0 since smp_callin() is not called.

__max_smt_threads must be a minimum of 1.

Fixes: b1cbacc8663a ("x86/smpboot: Do not use smp_num_siblings in 
__max_logical_packages calculation)
Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Cc: Jakub Kicinski <kubak...@wp.pl>
Cc: netdev@vger.kernel.org
Cc: "netdev@vger.kernel.org"
Cc: Clark Williams <willi...@redhat.com>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: x...@kernel.org
Cc: Thomas Gleixner <t...@linutronix.de>
Link: https://marc.info/?t=15124609214=1=2
---
 arch/x86/kernel/smpboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index eaee15fb7d8b..882c61e1d7a2 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -106,7 +106,7 @@ EXPORT_SYMBOL(__max_logical_packages);
 static unsigned int logical_packages __read_mostly;
 
 /* Maximum number of SMT threads on any online core */
-int __max_smt_threads __read_mostly;
+int __read_mostly __max_smt_threads = 1;
 
 /* Flag to indicate if a complete sched domain rebuild is required */
 bool x86_topology_update;
-- 
2.15.0.rc0.39.g2f0e14e64

Re: b1cbacc866 ("x86/smpboot: Do not use smp_num_siblings in .."): divide error: 0000 [#1] SMP DEBUG_PAGEALLOC

2017-12-05 Thread Prarit Bhargava 
>[0.029102] Hierarchical SRCU implementation.
>[0.030040] smp: Bringing up secondary CPUs ...
>[0.030528] smp: Brought up 1 node, 1 CPU
>[0.030953] divide error:  [#1] SMP DEBUG_PAGEALLOC
>[0.031000] Modules linked in:
>[0.031000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-01223-gb1cbacc 
>#1
>[0.031000] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>1.10.2-1 04/01/2014
>[0.031000] task: 88001e46 task.stack: c9008000

A single socket/package, single core, single thread system
has 1 thread.  __max_smt_threads is not set to 1 since smp_callin() is never
called.  The minimum value of __max_smt_threads must be 1.

tglx, this is built on -tip.

P.
8<

Subject: [PATCH] arch/x86: Initialize __max_smt_threads to 1

A single socket, single core, single thread system has __max_smt_threads
set to 0 since smp_callin() is not called.

__max_smt_threads must be a minimum of 1.

Fixes: b1cbacc8663a ("x86/smpboot: Do not use smp_num_siblings in 
__max_logical_packages calculation)
Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Cc: Jakub Kicinski <kubak...@wp.pl>
Cc: netdev@vger.kernel.org
Cc: "netdev@vger.kernel.org"
Cc: Clark Williams <willi...@redhat.com>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: x...@kernel.org
Link: https://marc.info/?t=15124609214=1=2
---
 arch/x86/kernel/smpboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index eaee15fb7d8b..882c61e1d7a2 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -106,7 +106,7 @@ EXPORT_SYMBOL(__max_logical_packages);
 static unsigned int logical_packages __read_mostly;
 
 /* Maximum number of SMT threads on any online core */
-int __max_smt_threads __read_mostly;
+int __read_mostly __max_smt_threads = 1;
 
 /* Flag to indicate if a complete sched domain rebuild is required */
 bool x86_topology_update;
-- 
2.15.0.rc0.39.g2f0e14e64

Re: [bisected] x86 boot still broken on -rc2

2017-12-04 Thread Prarit Bhargava 
On 12/04/2017 08:13 AM, Prarit Bhargava wrote:
> 
> 
> x86: Booting SMP configuration:
>  node  #0, CPUs:#1  #2  #3  #4
>  node  #1, CPUs:#5  #6  #7  #8  #9
>  node  #0, CPUs:   #10 #11 #12 #13 #14
>  node  #1, CPUs:   #15 #16 #17 #18 #19
> smp: Brought up 2 nodes, 20 CPUs
> smpboot: Max logical packages: 1
> 
> which means that the calculation of logical packages is wrong because
> 
>   ncpus = cpu_data(0).booted_cores * smp_num_siblings;
>   ncpus = 10 * 2;
>   ncpus = 20;
> 
> smp_num_siblings is defined as "The number of threads in a core" which
> should be 1 if HT/SMT is disabled.
> 
> It looks like my patch has exposed a bug in the
> smp_num_siblings calculation.   I'm still debugging ...

The bug is that smp_num_siblings has been incorrectly calculated as the
*maximum* number of threads in a core, and not the actual number of threads in
a core on systems which have a CPUID level greater than 0xb.  (see
arch/x86/kernel/cpu/topology.c:59)

That will take some time to investigate and come up with a proper solution and
fix.  In the meantime, the patch below will fix the problem in the short-term.
I've tested the patch using SMT enabled, SMT disabled, maxcpus=1 and nr_cpus=1.

tglx, Please revert b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages
estimate") if you think that is a better option.  The problem with
smp_num_siblings has been around for almost a decade.

P.

---8<---

Subject: [PATCH] arch/x86: Do not use smp_num_siblings in
 __max_logical_packages calculation

Documentation/x86/topology.txt defines smp_num_siblings as "The number of
threads in a core".  Since commit bbb65d2d365e ("x86: use cpuid vector 0xb
when available for detecting cpu topology") smp_num_siblings is the
maximum number of threads in a core.  If Simultaneous MultiThreading
(SMT) is disabled on a system, smp_num_siblings is 2 and not 1 as
expected.

Use topology_max_smt_threads() in the __max_logical_packages calculation.

Signed-off-by: Prarit Bhargava <pra...@redhat.com
Cc: Jakub Kicinski <kubak...@wp.pl>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Clark Williams <willi...@redhat.com>
---
 arch/x86/kernel/smpboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 3d01df7d7cf6..eaee15fb7d8b 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1304,7 +1304,7 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
 * Today neither Intel nor AMD support heterogenous systems so
 * extrapolate the boot cpu's data to all packages.
 */
-   ncpus = cpu_data(0).booted_cores * smp_num_siblings;
+   ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
 
-- 
1.8.3.1

Re: [bisected] x86 boot still broken on -rc2

2017-12-04 Thread Prarit Bhargava 


On 12/04/2017 07:28 AM, Prarit Bhargava wrote:
> 
> 
> On 12/03/2017 08:28 PM, Jakub Kicinski wrote:
>> Same thing on rc2, bisected down to:
>>
>> commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad)
>> Author: Prarit Bhargava <pra...@redhat.com>
>> Date:   Tue Nov 14 07:42:57 2017 -0500
>>
>> x86/smpboot: Fix __max_logical_packages estimate
>> 
>> A system booted with a small number of cores enabled per package
>> panics because the estimate of __max_logical_packages is too low.
>> 
>> This occurs when the total number of active cores across all packages is
>> less than the maximum core count for a single package. e.g.:
>> 
>>   On a 4 package system with 20 cores/package where only 4 cores are
>>   enabled on each package, the value of __max_logical_packages is
>>   calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
>> 
>> Calculate __max_logical_packages after the cpu enumeration has completed.
>> Use the boot cpu's data to extrapolate the number of packages.
>> 
>> Signed-off-by: Prarit Bhargava <pra...@redhat.com>
>> Signed-off-by: Thomas Gleixner <t...@linutronix.de>
>> Cc: Tom Lendacky <thomas.lenda...@amd.com>
>> Cc: Andi Kleen <a...@linux.intel.com>
>> Cc: Christian Borntraeger <borntrae...@de.ibm.com>
>> Cc: Peter Zijlstra <pet...@infradead.org>
>> Cc: Kan Liang <kan.li...@intel.com>
>> Cc: He Chen <he.c...@linux.intel.com>
>> Cc: Stephane Eranian <eran...@google.com>
>> Cc: Dave Hansen <dave.han...@intel.com>
>> Cc: Piotr Luc <piotr@intel.com>
>> Cc: Andy Lutomirski <l...@kernel.org>
>> Cc: Arvind Yadav <arvind.yadav...@gmail.com>
>> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com>
>> Cc: Borislav Petkov <b...@suse.de>
>> Cc: Tim Chen <tim.c.c...@linux.intel.com>
>> Cc: Mathias Krause <mini...@googlemail.com>
>> Cc: "Kirill A. Shutemov" <kirill.shute...@linux.intel.com>
>> Link: https://lkml.kernel.org/r/20171114124257.22013-4-pra...@redhat.com
>>
>>
>> On Fri, 1 Dec 2017 16:39:54 -0800, Jakub Kicinski wrote:
>>> Hi!
>>>
>>> I'm hitting these after DaveM pulled rc1 into net-next on my Xeon
>>> E5-2630 v4 box.  It also happens on linux-next.  Did anyone else
>>> experience it?  (.config attached)
>>>
>>> [5.003771] WARNING: CPU: 14 PID: 1 at 
>>> ../arch/x86/events/intel/uncore.c:936 uncore_pci_probe+0x285/0x2b0
>>> [5.007544] Modules linked in:
>>> [5.007544] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 
>>> 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
>>> [5.007544] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 
>>> 11/08/2016
> 
> I have a Dell R730 available for use.  OOC are you booting with the default
> BIOS options?
>

Jakub, I was able to reproduce this on a similar system by DISABLING
hyperthreading in the BIOS.  Doing this on other systems seems to have no
impact.  What is odd about this system when booting is that the
kernel claims that hyperthreading is ENABLED:

x86: Booting SMP configuration:
 node  #0, CPUs:#1  #2  #3  #4
 node  #1, CPUs:#5  #6  #7  #8  #9
 node  #0, CPUs:   #10 #11 #12 #13 #14
 node  #1, CPUs:   #15 #16 #17 #18 #19
smp: Brought up 2 nodes, 20 CPUs
smpboot: Max logical packages: 1

which means that the calculation of logical packages is wrong because

ncpus = cpu_data(0).booted_cores * smp_num_siblings;
ncpus = 10 * 2;
ncpus = 20;

smp_num_siblings is defined as "The number of threads in a core" which
should be 1 if HT/SMT is disabled.

It looks like my patch has exposed a bug in the
smp_num_siblings calculation.   I'm still debugging ...

FWIW, I did test this code on systems by disabling HT/SMT in BIOS on
several systems.  I have tested those systems again and don't see a
problem.  It is something peculiar to a few systems.

P.

Re: [bisected] x86 boot still broken on -rc2

2017-12-04 Thread Prarit Bhargava 


On 12/03/2017 08:28 PM, Jakub Kicinski wrote:
> Same thing on rc2, bisected down to:
> 
> commit b4c0a7326f5dc0ef7a64128b0ae7d081f4b2cbd1 (refs/bisect/bad)
> Author: Prarit Bhargava <pra...@redhat.com>
> Date:   Tue Nov 14 07:42:57 2017 -0500
> 
> x86/smpboot: Fix __max_logical_packages estimate
> 
> A system booted with a small number of cores enabled per package
> panics because the estimate of __max_logical_packages is too low.
> 
> This occurs when the total number of active cores across all packages is
> less than the maximum core count for a single package. e.g.:
> 
>   On a 4 package system with 20 cores/package where only 4 cores are
>   enabled on each package, the value of __max_logical_packages is
>   calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4.
> 
> Calculate __max_logical_packages after the cpu enumeration has completed.
> Use the boot cpu's data to extrapolate the number of packages.
> 
> Signed-off-by: Prarit Bhargava <pra...@redhat.com>
> Signed-off-by: Thomas Gleixner <t...@linutronix.de>
> Cc: Tom Lendacky <thomas.lenda...@amd.com>
> Cc: Andi Kleen <a...@linux.intel.com>
> Cc: Christian Borntraeger <borntrae...@de.ibm.com>
> Cc: Peter Zijlstra <pet...@infradead.org>
> Cc: Kan Liang <kan.li...@intel.com>
> Cc: He Chen <he.c...@linux.intel.com>
> Cc: Stephane Eranian <eran...@google.com>
> Cc: Dave Hansen <dave.han...@intel.com>
> Cc: Piotr Luc <piotr@intel.com>
> Cc: Andy Lutomirski <l...@kernel.org>
> Cc: Arvind Yadav <arvind.yadav...@gmail.com>
> Cc: Vitaly Kuznetsov <vkuzn...@redhat.com>
> Cc: Borislav Petkov <b...@suse.de>
> Cc: Tim Chen <tim.c.c...@linux.intel.com>
> Cc: Mathias Krause <mini...@googlemail.com>
> Cc: "Kirill A. Shutemov" <kirill.shute...@linux.intel.com>
> Link: https://lkml.kernel.org/r/20171114124257.22013-4-pra...@redhat.com
> 
> 
> On Fri, 1 Dec 2017 16:39:54 -0800, Jakub Kicinski wrote:
>> Hi!
>>
>> I'm hitting these after DaveM pulled rc1 into net-next on my Xeon
>> E5-2630 v4 box.  It also happens on linux-next.  Did anyone else
>> experience it?  (.config attached)
>>
>> [5.003771] WARNING: CPU: 14 PID: 1 at 
>> ../arch/x86/events/intel/uncore.c:936 uncore_pci_probe+0x285/0x2b0
>> [5.007544] Modules linked in:
>> [5.007544] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 
>> 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
>> [5.007544] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 
>> 11/08/2016

I have a Dell R730 available for use.  OOC are you booting with the default
BIOS options?

P.


>> [5.007544] task: 9e842725 task.stack: 8a63fd2d
>> [5.007544] RIP: 0010:uncore_pci_probe+0x285/0x2b0
>> [5.007544] RSP: :ad8580163d10 EFLAGS: 00010286
>> [5.007544] RAX: 98576cc3df30 RBX: b08037e0 RCX: 
>> b0c1a120
>> [5.007544] RDX:  RSI:  RDI: 
>> b0c1a960
>> [5.007544] RBP: 985b6c00ac00 R08: fffe R09: 
>> 000f
>> [5.007544] R10: 98576f1b6018 R11: 0022 R12: 
>> 985b6c641000
>> [5.007544] R13: 0001 R14: 0001 R15: 
>> 0001
>> [5.007544] FS:  () GS:98576fb8() 
>> knlGS:
>> [5.007544] CS:  0010 DS:  ES:  CR0: 80050033
>> [5.007544] CR2:  CR3: 000185c09001 CR4: 
>> 003606e0
>> [5.007544] DR0:  DR1:  DR2: 
>> 
>> [5.007544] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [5.007544] Call Trace:
>> [5.007544]  local_pci_probe+0x3d/0x90
>> [5.007544]  ? pci_match_device+0xd9/0x100
>> [5.007544]  pci_device_probe+0x122/0x180
>> [5.007544]  driver_probe_device+0x246/0x330
>> [5.007544]  ? set_debug_rodata+0x11/0x11
>> [5.007544]  __driver_attach+0x8a/0x90
>> [5.007544]  ? driver_probe_device+0x330/0x330
>> [5.007544]  bus_for_each_dev+0x5c/0x90
>> [5.007544]  bus_add_driver+0x196/0x220
>> [5.007544]  driver_register+0x57/0xc0
>> [5.007544]  intel_uncore_init+0x1e3/0x249
>> [5.007544]  ? uncore_type_init+0x193/0x193
>> [5.007544]  ? set_debug_rodata+0x11/0x11
>> [5.007544]  do_one_initcall+0x4b/0x190
>> [5.007544]  kernel_init_f

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-15 Thread Prarit Bhargava 


On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote:
> On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote:
>>> If I understad correctly this error happen 100% of the time, not only during
>>> init. Hence seems there is an issue here, i.e. cur_ucode is not marked
>>> correctly as IWL_UCODE_REGULAR or iwl_mvm_get_temp() fail 100% of the
>>> time (iwl_mvm_is_tt_in_fw() incorrecly return true on Prarit device ? ).
>>
>> Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware which
>> will happen upon ifup.
> 
> Then creating thermal_device on ifup looks more reasonable to me.
> Otherwise we can create device that can be non-functional virtually
> forever, i.e. when soft RFKILL is enabled. However I admit that
> creating thermal_device when HW is detected has some advantages
> too.

That's my plan right now.  Unfortunately something else in the kernel seems
recently broken and is preventing me from testing.  I will get back to this
early next week.

P.
> 
> Stanislaw
>

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Prarit Bhargava 


On 07/13/2016 03:24 AM, Luca Coelho wrote:
> On Wed, 2016-07-13 at 09:50 +0300, Kalle Valo wrote:
>> Prarit Bhargava <pra...@redhat.com> writes:
>>
>>>> We implement thermal zone because we do support it, but the
>>>> problem is
>>>> that we need the firmware to be loaded for that. So you can argue
>>>> that
>>>> we should register *later* when the firmware is loaded. But this
>>>> is
>>>> really not helping all that much because the firmware can also be
>>>> stopped at any time. So you'd want us to register / unregister
>>>> the
>>>> thermal zone anytime the firmware is loaded / unloaded?
>>>
>>> You might have to do that.  I think that if the firmware enables a
>>> feature then
>>> the act of loading the firmware should run the code that enables
>>> the feature.
>>> IMO of course.
>>
>> But I suspect that the iwlwifi firmware is loaded during interface up
>> (and unloaded during interface down) and in that case
>> register/unregister would be happening all the time. That doesn't
>> sound
>> like a good idea. I would rather try to fix the thermal interface to
>> handle the cases when the measurement is not available.
> 
> I totally agree with Emmanuel and Kalle.  We should not change this.
>  It is a design decision to return an error when the interface is down,
> this is very common with other subsystems as well.  

Please show me another subsystem or driver that does this.  I've looked around
the kernel but cannot find one that updates the firmware and implements new
features on the fly like this.  I have come across several drivers that allow
for an update, but they do not implement new features based on the firmware.

Additionally, what happens when someone back revs firmware versions (which
happens far more than you and I would expect)?  Does that mean I now go from a
functional system to a non-functional system wrt to userspace?

The userspace
> should be able to handle errors and report something like "unavailable"
> when this kind of error is returned.
> 

I myself have made the same arguments wrt to cpufreq code & bad userspace
choices.  I just went through this a few months back with what went from a
simple patch and turned out to be a hideous patch in cpufreq.  You cannot break
userspace like this.

See commit 51443fbf3d2c ("cpufreq: intel_pstate: Fix intel_pstate powersave
min_perf_pct value").  What should have been a trivial change resulted in a
massive change because of broken userspace.

> I'm not sure EIO is the best we can have, but for me that's exactly
> what it is.  The thermal zone *is* there, but cannot be accessed
> because the firmware is not available.  I'm okay to change it to EBUSY,
> if that would help userspace, but I think that's a bit misleading.  The
> device is not busy, on the contrary, it's not even running at all.
> 

I understand that, but by returning -EIO we end up with an error.

> Furthermore, I don't think this is "breaking userspace" in the sense of
> being a regression.  

I run (let's say 4.5 kernel).  sensors works.  I update to 4.7.  sensors doesn't
work.  How is that not a regression?  That's _exactly_ what it should be
reported as.

The userspace API has always been implemented with
> the possibility of returning errors.  It's not a good design if a
> single device returning an error causes all the other devices to also
> fail.
> 

If that were the case we would never have to worry about "breaking userspace"?
For any kernel change I could just say that the userspace design was bad and be
done with it.  Why fix anything then?

I don't see any harm in waiting to register the sysfs files for hwmon until the
firmware has been validated.  IIUC, the up/down'ing of the device doesn't happen
that often (during initial boot, and suspend/resume, switching wifi connections,
shutdown?).  This would make the iwlwifi community happy (IMO) and sensors would
still work.  At the same time I could write a patch for lm-sensors to fix this
issue if it comes up in future versions.  [Aside: I'm going to have the
reproducing system available today and will test this out.  It looks like just
moving some code around.]

The bottom line is that lm-sensors is currently broken with this change in
iwlwifi.  AFAICT, no other thermal device returns an error this way, and IMO
that means the iwlwifi driver is doing something new and unexpected wrt to
userspace.

P.


> --
> Cheers,
> Luca.
>

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-13 Thread Prarit Bhargava 


On 07/13/2016 02:50 AM, Kalle Valo wrote:
> Prarit Bhargava <pra...@redhat.com> writes:
> 
>>> We implement thermal zone because we do support it, but the problem is
>>> that we need the firmware to be loaded for that. So you can argue that
>>> we should register *later* when the firmware is loaded. But this is
>>> really not helping all that much because the firmware can also be
>>> stopped at any time. So you'd want us to register / unregister the
>>> thermal zone anytime the firmware is loaded / unloaded?
>>
>> You might have to do that.  I think that if the firmware enables a feature 
>> then
>> the act of loading the firmware should run the code that enables the feature.
>> IMO of course.
> 
> But I suspect that the iwlwifi firmware is loaded during interface up
> (and unloaded during interface down) and in that case
> register/unregister would be happening all the time. 

You make it sound like the interface is coming and going a 1000 times a second.
 Maybe this happens once during runtime & during suspend/resume cycles?  What
about the cases when the firmware isn't present (and that's what lead me to this
bug)?

That doesn't sound
> like a good idea. I would rather try to fix the thermal interface to
> handle the cases when the measurement is not available.
> 

Userspace is broken because of this change.  I've had to make another horrible
change to cpufreq for a similar change so I don't see the argument here to just
blame userspace and ignore the outcome of the patch.

P.

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-11 Thread Prarit Bhargava 


On 07/11/2016 02:27 PM, Grumbach, Emmanuel wrote:
> On Mon, 2016-07-11 at 14:19 -0400, Prarit Bhargava wrote:
>>
>> On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
>>> On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava <pra...@redhat.com
>>>> wrote:
>>>>
>>>> Didn't get any feedback or review comments on this patch. 
>>>>  Resending ...
>>>>
>>>> P.
>>>
>>> This change is obviously completely broken. It simply disables the
>>> registration to thermal zone core.
>>
>> No it is not broken, and yes, that is exactly what should happen IMO.
>>
>> The problem is that the iwlwifi driver implements the thermal zone
>> even when the
>> device doesn't support it.
> 
> We implement thermal zone because we do support it, but the problem is
> that we need the firmware to be loaded for that. So you can argue that
> we should register *later* when the firmware is loaded. But this is
> really not helping all that much because the firmware can also be
> stopped at any time. So you'd want us to register / unregister the
> thermal zone anytime the firmware is loaded / unloaded?

You might have to do that.  I think that if the firmware enables a feature then
the act of loading the firmware should run the code that enables the feature.
IMO of course.

> I guess that works, but it seems wrong to me. Usually, registration
> should happen only upon INIT, and yes, at that time the firmware is not
> ready to provide the information yet.
> Maybe returning -EBUSY would help lm-sensors not to get confused?

I'll give that a shot, but I expect that won't work either as an error message
will still be displayed.

> 
>>
>> As can be seen in the current code base, iwl_mvm_tzone_get_temp()
>> will return
>> -EIO 100% of the time when the firmware doesn't support reading the
>> temperature[1].  In this case a read of sysfs will result in a return
>> of -EIO,
>> and this breaks existing userspace programs such as lm-sensors (which
>> by all
>> accounts is bad to do).
> 
> Right, but I don't understand why the userspace is broken because of
> that? 

Before the iwlwifi change, sensors successfully returned.  Now, because of the
error, it doesn't.

Unless we register / unregister anytime the firmware is loaded, I
> don't see any proper way to fix this. And yes, I'd expect the userspace
> to handle gracefully failures in its requests.

I agree with you in principle *and there's a great many things I wish userspace
would do gracefully* but updating the kernel shouldn't result in userspace
programs failing.

> 
>>
>> Note that in my patch I have removed the -EIO return in favor of not
>> registering
>> the non-existent thermal zone.  I'm not removing any functionality by
>> changing
>> this, nor am I adding functionality.  In both cases the thermal zone
>> is not
>> functional, and with my patch userspace continues to work.
> 
> You are removing the thermal zone functionality since even when the
> firmware will be loaded (which typically happens fairly quickly),
> thermal zone won't work.

Then I agree with your suggestion above that you need to enable the thermal zone
on a successful load of the firmware.  [Aside: I wonder what other drivers do in
this situation?  While this does seem like an odd case, I can't believe that the
iwlwifi driver is the only driver to enable features based on firmware.]

P.

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-11 Thread Prarit Bhargava 


On 07/11/2016 02:00 PM, Emmanuel Grumbach wrote:
> On Mon, Jul 11, 2016 at 6:18 PM, Prarit Bhargava <pra...@redhat.com> wrote:
>>
>> Didn't get any feedback or review comments on this patch.  Resending ...
>>
>> P.
> 
> This change is obviously completely broken. It simply disables the
> registration to thermal zone core.

No it is not broken, and yes, that is exactly what should happen IMO.

The problem is that the iwlwifi driver implements the thermal zone even when the
device doesn't support it.

As can be seen in the current code base, iwl_mvm_tzone_get_temp() will return
-EIO 100% of the time when the firmware doesn't support reading the
temperature[1].  In this case a read of sysfs will result in a return of -EIO,
and this breaks existing userspace programs such as lm-sensors (which by all
accounts is bad to do).

Note that in my patch I have removed the -EIO return in favor of not registering
the non-existent thermal zone.  I'm not removing any functionality by changing
this, nor am I adding functionality.  In both cases the thermal zone is not
functional, and with my patch userspace continues to work.

P.

[1] iwl_mvm_tzone_set_trip_temp() also returns -EIO, so setting and getting of
the temperature is non-functional.


> 
>>
>> ---8<---
>>
>> The iwlwifi driver implements a thermal zone and hwmon device, but
>> returns -EIO on temperature reads if the firmware isn't loaded.  This
>> results in the error
>>
>> iwlwifi-virtual-0
>> Adapter: Virtual device
>> ERROR: Can't get value of subfeature temp1_input: I/O error
>> temp1:N/A
>>
>> being output when using sensors from the lm-sensors package.  Since
>> the temperature cannot be read unless the ucode is loaded there is no
>> reason to add the interface only to have it return an error 100% of
>> the time.
>>
>> This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
>> stops the thermal zone from being created if the ucode hasn't been loaded.
>>
>> Signed-off-by: Prarit Bhargava <pra...@redhat.com>
>> Cc: Johannes Berg <johannes.b...@intel.com>
>> Cc: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
>> Cc: Luca Coelho <luciano.coe...@intel.com>
>> Cc: Intel Linux Wireless <linuxw...@intel.com>
>> Cc: Kalle Valo <kv...@codeaurora.org>
>> Cc: Chaya Rachel Ivgi <chaya.rachel.i...@intel.com>
>> Cc: Sara Sharon <sara.sha...@intel.com>
>> Cc: linux-wirel...@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> ---
>>  drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
>>  1 file changed, 3 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
>> b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> index 58fc7b3c711c..64802659711f 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
>> @@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct 
>> thermal_zone_device *device,
>>
>> mutex_lock(>mutex);
>>
>> -   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
>> -   ret = -EIO;
>> -   goto out;
>> -   }
>> -
>> ret = iwl_mvm_get_temp(mvm, );
>> if (ret)
>> goto out;
>> @@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct 
>> thermal_zone_device *device,
>>
>> mutex_lock(>mutex);
>>
>> -   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
>> -   ret = -EIO;
>> -   goto out;
>> -   }
>> -
>> if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
>> ret = -EINVAL;
>> goto out;
>> @@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm 
>> *mvm)
>> return;
>> }
>>
>> +   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
>> +   return;
>> +
>> BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
>>
>> mvm->tz_device.tzone = thermal_zone_device_register(name,
>> --
>> 1.7.9.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-11 Thread Prarit Bhargava 


On 07/11/2016 12:07 PM, Coelho, Luciano wrote:
> On Mon, 2016-07-11 at 11:18 -0400, Prarit Bhargava wrote:
>> Didn't get any feedback or review comments on this patch.  Resending
>> ...
>>
>> P.
> 
> Sorry, this got flooded down my inbox.

NP, Luciano -- My worry was that it hadn't been seen or didn't make it out to
the list.

I'm being a bit impatient too ;)

P.

> 
> 
>> ---8<---
>>
>> The iwlwifi driver implements a thermal zone and hwmon device, but
>> returns -EIO on temperature reads if the firmware isn't loaded.  This
>> results in the error
>>
>> iwlwifi-virtual-0
>> Adapter: Virtual device
>> ERROR: Can't get value of subfeature temp1_input: I/O error
>> temp1:N/A
>>
>> being output when using sensors from the lm-sensors package.  Since
>> the temperature cannot be read unless the ucode is loaded there is no
>> reason to add the interface only to have it return an error 100% of
>> the time.
>>
>> This patch moves the firmware check to
>> iwl_mvm_thermal_zone_register() and
>> stops the thermal zone from being created if the ucode hasn't been
>> loaded.
>>
>> Signed-off-by: Prarit Bhargava <pra...@redhat.com>
>> Cc: Johannes Berg <johannes.b...@intel.com>
>> Cc: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
>> Cc: Luca Coelho <luciano.coe...@intel.com>
>> Cc: Intel Linux Wireless <linuxw...@intel.com>
>> Cc: Kalle Valo <kv...@codeaurora.org>
>> Cc: Chaya Rachel Ivgi <chaya.rachel.i...@intel.com>
>> Cc: Sara Sharon <sara.sha...@intel.com>
>> Cc: linux-wirel...@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> ---
> 
> I have now sent it for review on our internal tree.
> 
> --
> Luca.
>

[PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-11 Thread Prarit Bhargava 
Didn't get any feedback or review comments on this patch.  Resending ...

P.

---8<---

The iwlwifi driver implements a thermal zone and hwmon device, but
returns -EIO on temperature reads if the firmware isn't loaded.  This
results in the error

iwlwifi-virtual-0
Adapter: Virtual device
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A

being output when using sensors from the lm-sensors package.  Since
the temperature cannot be read unless the ucode is loaded there is no
reason to add the interface only to have it return an error 100% of
the time.

This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
stops the thermal zone from being created if the ucode hasn't been loaded.

Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Cc: Johannes Berg <johannes.b...@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
Cc: Luca Coelho <luciano.coe...@intel.com>
Cc: Intel Linux Wireless <linuxw...@intel.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: Chaya Rachel Ivgi <chaya.rachel.i...@intel.com>
Cc: Sara Sharon <sara.sha...@intel.com>
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 58fc7b3c711c..64802659711f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
ret = iwl_mvm_get_temp(mvm, );
if (ret)
goto out;
@@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
ret = -EINVAL;
goto out;
@@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm 
*mvm)
return;
}
 
+   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
+   return;
+
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
 
mvm->tz_device.tzone = thermal_zone_device_register(name,
-- 
1.7.9.3

[PATCH] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-06 Thread Prarit Bhargava 
The iwlwifi driver implements a thermal zone and hwmon device, but
returns -EIO on temperature reads if the firmware isn't loaded.  This
results in the error

iwlwifi-virtual-0
Adapter: Virtual device
ERROR: Can't get value of subfeature temp1_input: I/O error
temp1:N/A

being output when using sensors from the lm-sensors package.  Since
the temperature cannot be read unless the ucode is loaded there is no
reason to add the interface only to have it return an error 100% of
the time.

This patch moves the firmware check to iwl_mvm_thermal_zone_register() and
stops the thermal zone from being created if the ucode hasn't been loaded.

Signed-off-by: Prarit Bhargava <pra...@redhat.com>
Cc: Johannes Berg <johannes.b...@intel.com>
Cc: Emmanuel Grumbach <emmanuel.grumb...@intel.com>
Cc: Luca Coelho <luciano.coe...@intel.com>
Cc: Intel Linux Wireless <linuxw...@intel.com>
Cc: Kalle Valo <kv...@codeaurora.org>
Cc: Chaya Rachel Ivgi <chaya.rachel.i...@intel.com>
Cc: Sara Sharon <sara.sha...@intel.com>
Cc: linux-wirel...@vger.kernel.org
Cc: netdev@vger.kernel.org
---
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
index 58fc7b3c711c..64802659711f 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
@@ -634,11 +634,6 @@ static int iwl_mvm_tzone_get_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
ret = iwl_mvm_get_temp(mvm, );
if (ret)
goto out;
@@ -684,11 +679,6 @@ static int iwl_mvm_tzone_set_trip_temp(struct 
thermal_zone_device *device,
 
mutex_lock(>mutex);
 
-   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR)) {
-   ret = -EIO;
-   goto out;
-   }
-
if (trip < 0 || trip >= IWL_MAX_DTS_TRIPS) {
ret = -EINVAL;
goto out;
@@ -750,6 +740,9 @@ static void iwl_mvm_thermal_zone_register(struct iwl_mvm 
*mvm)
return;
}
 
+   if (!mvm->ucode_loaded || !(mvm->cur_ucode == IWL_UCODE_REGULAR))
+   return;
+
BUILD_BUG_ON(ARRAY_SIZE(name) >= THERMAL_NAME_LENGTH);
 
mvm->tz_device.tzone = thermal_zone_device_register(name,
-- 
1.7.9.3

Re: [PATCH 9/9] treewide: Remove newlines inside DEFINE_PER_CPU() macros

2015-10-22 Thread Prarit Bhargava 


On 10/21/2015 03:52 PM, Michal Marek wrote:
> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>> On 10/15/2015 04:16 PM, Michal Marek wrote:
>>> Otherwise make tags can't parse them:
>>>
>>> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern 
>>> "\1"
>>> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
>>> pattern "\1"
>>> ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
>>> pattern "\1"
>>> ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name 
>>> pattern "\1"
>>> ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern "\1"
>>> ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name pattern 
>>> "\1"
>>> ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name pattern 
>>> "\1"
>>> ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
>>> ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern 
>>> "\1"
>>> ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern 
>>> "\1"
>>
>> I guarantee you're going to end up fixing this issue over and over again as 
>> more
>> code is added in.
> 
> This is certainly going to happen, but it should be quickly spotted by
> anybody running make tags on linux-next. And 10 instances since the
> beginning of git is not too many.

Not everyone uses 'make tags'.  'make cscope' exists and functions correctly ;)

> 
> 
>> OOC, why not fix ctags to recognize newlines?
> 
> It's not ctags itself parsing the DEFINE_PER_CPU() macro, but a
> user-supplied regex specified on commandline. Which can only operate on
> single lines.
> 

What's the regex?

P.

> Michal
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 9/9] treewide: Remove newlines inside DEFINE_PER_CPU() macros

2015-10-22 Thread Prarit Bhargava 


On 10/22/2015 08:06 AM, Michal Marek wrote:
> On 2015-10-22 13:31, Prarit Bhargava wrote:
>>
>>
>> On 10/21/2015 03:52 PM, Michal Marek wrote:
>>> Dne 21.10.2015 v 21:27 Prarit Bhargava napsal(a):
>>>> On 10/15/2015 04:16 PM, Michal Marek wrote:
>>>>> Otherwise make tags can't parse them:
>>>>>
>>>>> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern 
>>>>> "\1"
>>>>> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
>>>>> pattern "\1"
>>>>> ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
>>>>> pattern "\1"
>>>>> ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name 
>>>>> pattern "\1"
>>>>> ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern 
>>>>> "\1"
>>>>> ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name 
>>>>> pattern "\1"
>>>>> ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name 
>>>>> pattern "\1"
>>>>> ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
>>>>> ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern 
>>>>> "\1"
>>>>> ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern 
>>>>> "\1"
>>>>
>>>> I guarantee you're going to end up fixing this issue over and over again 
>>>> as more
>>>> code is added in.
>>>
>>> This is certainly going to happen, but it should be quickly spotted by
>>> anybody running make tags on linux-next. And 10 instances since the
>>> beginning of git is not too many.
>>
>> Not everyone uses 'make tags'.  'make cscope' exists and functions correctly 
>> ;)
> 
> cscope works, but unfortunately it cannot be extended to understand the
> preprocessor constructs. But it does not suffer from the problem at
> hand, obviously.
> 
> 
>>> It's not ctags itself parsing the DEFINE_PER_CPU() macro, but a
>>> user-supplied regex specified on commandline. Which can only operate on
>>> single lines.
>>>
>>
>> What's the regex?
> 
> See
> https://lkml.kernel.org/r/1444940195-28272-9-git-send-email-mma...@suse.com
> 
> It used to require a closing parenthesis, so it would not match the
> multiline macro invocations at all. Now it matches them, but ctags
> correctly warns that the empty string is probably not what we intended
> to match.

It seems wrong to change kernel code, not for a bug, but for a userspace search.

P.

> 
> Michal
> 
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 9/9] treewide: Remove newlines inside DEFINE_PER_CPU() macros

2015-10-21 Thread Prarit Bhargava 
On 10/15/2015 04:16 PM, Michal Marek wrote:
> Otherwise make tags can't parse them:
> 
> ctags: Warning: arch/ia64/kernel/smp.c:60: null expansion of name pattern "\1"
> ctags: Warning: drivers/xen/events/events_2l.c:41: null expansion of name 
> pattern "\1"
> ctags: Warning: drivers/acpi/processor_idle.c:64: null expansion of name 
> pattern "\1"
> ctags: Warning: kernel/locking/lockdep.c:153: null expansion of name pattern 
> "\1"
> ctags: Warning: kernel/workqueue.c:305: null expansion of name pattern "\1"
> ctags: Warning: kernel/rcu/rcutorture.c:133: null expansion of name pattern 
> "\1"
> ctags: Warning: kernel/rcu/rcutorture.c:135: null expansion of name pattern 
> "\1"
> ctags: Warning: net/rds/page.c:45: null expansion of name pattern "\1"
> ctags: Warning: net/ipv4/syncookies.c:53: null expansion of name pattern "\1"
> ctags: Warning: net/ipv6/syncookies.c:44: null expansion of name pattern "\1"
> 
> Cc: linux-i...@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-a...@vger.kernel.org
> Cc: rds-de...@oss.oracle.com
> Cc: netdev@vger.kernel.org
> Signed-off-by: Michal Marek 
> ---
>  arch/ia64/kernel/smp.c | 3 +--
>  drivers/acpi/processor_idle.c  | 3 +--
>  drivers/xen/events/events_2l.c | 3 +--
>  kernel/locking/lockdep.c   | 3 +--
>  kernel/rcu/rcutorture.c| 6 ++
>  kernel/workqueue.c | 3 +--
>  net/ipv4/syncookies.c  | 3 +--
>  net/ipv6/syncookies.c  | 3 +--
>  net/rds/page.c | 3 +--
>  9 files changed, 10 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
> index 7f706d4f84f7..1dcfe29d8a42 100644
> --- a/arch/ia64/kernel/smp.c
> +++ b/arch/ia64/kernel/smp.c
> @@ -57,8 +57,7 @@ static struct local_tlb_flush_counts {
>   unsigned int count;
>  } __attribute__((__aligned__(32))) local_tlb_flush_counts[NR_CPUS];
>  
> -static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS],
> -  shadow_flush_counts);
> +static DEFINE_PER_CPU_SHARED_ALIGNED(unsigned short [NR_CPUS], 
> shadow_flush_counts);
>  

I guarantee you're going to end up fixing this issue over and over again as more
code is added in.

OOC, why not fix ctags to recognize newlines?

P.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html