Re: perf: Add support for full Intel event lists v5
On Fri, 30 May 2014 14:50:06 -0700, Andi Kleen wrote: > [v2: Review feedback addressed and some minor improvements] > [v3: More review feedback addressed and handle test failures better. > Ported to latest tip/core.] > [v4: Addressed Namhyung's feedback] > [v5: Rebase to latest tree. Minor description update.] > > perf has high level events which are useful in many cases. However > there are some tuning situations where low level events in the CPU > are needed. Traditionally this required specifying the event in > raw form (very awkward) or using non standard frontends > like ocperf or patching in libpfm. > > Intel CPUs can have very large event files (Haswell has ~336 core events, > much more if you add uncore or all the offcore combinations), which is too > large to describe through the kernel interface. It would require tying up > significant amounts of unswappable memory for this. > > oprofile always had separate event list files that were maintained by > the CPU vendors. The oprofile events were shipped with the tool. > The Intel events get updated regularly, for example to add references > to the specification updates or add new events. > > Unfortunately oprofile usually did not keep up with these updates, > so the events in oprofile were often out of date. In addition > it ties up quite a bit of disk space, mostly for CPUs you don't have. > > This patch kit implements another mechanism that avoids these problems. > Intel releases the event lists for CPUs in a standardized JSON format > on a download server. > > I implemented an automatic downloader to get the event file for the > current CPU. The events are stored in ~/.cache/pmu-events. > Then perf adds a parser that converts the JSON format into perf event > aliases, which then can be used directly as any other perf event. > > The parsing is done using a simple existing JSON library. > > The events are still abstracted for perf, but the abstraction mechanism is > through the downloaded file instead of through the kernel. > > The JSON format and perf parser has some minor Intelisms, but they > are simple and small and optional. It's easy to extend, so it would be > possible to use it for other CPUs too, add different pmu attributes, and > add new download sites to the downloader tool. > > Currently only core events are supported, uncore may come at a later > point. No kernel changes, all code in perf user tools only. > > Some of the parser files are partially shared with separate event parser > library and are thus 2-clause BSD licensed. So I played with this patchset for a little while, and it's mostly good and I left comments for each patch I have concerns. With that change, Acked-by: Namhyung Kim Hopefully other vendors will add support for their cpus too. Thanks, Namhyung > > Patches also available from > git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/json > > Example output: > > % perf download > Downloading models file > Downloading readme.txt > 2014-03-05 10:39:33 URL:https://download.01.org/perfmon/readme.txt > [10320/10320] -> "readme.txt" [1] > 2014-03-05 10:39:34 URL:https://download.01.org/perfmon/mapfile.csv > [1207/1207] -> "mapfile.csv" [1] > Downloading events file > % perf list > ... > br_inst_exec.all_branches [Speculative and retired > branches] > br_inst_exec.all_conditional [Speculative and retired > macro-conditional > branches] > br_inst_exec.all_direct_jmp[Speculative and retired > macro-unconditional > branches excluding > calls and indirects] > ... 333 more new events ... > > % perf stat -e br_inst_exec.all_direct_jmp true > > Performance counter stats for 'true': > > 6,817 cpu/br_inst_exec.all_direct_jmp/ > > >0.003503212 seconds time elapsed > > One nice feature is that a pointer to the specification update is now > included in the description, which will hopefully clear up many problems: > > % perf list > ... > mem_load_uops_l3_hit_retired.xsnp_hit [Retired load uops which > data sources were L3 > and cross-core snoop > hits in on-pkg core > cache. Supports address > when precise. Spec > update: HSM26, HSM30 > (Precise event)] > ... > > > -Andi
Re: [PATCH 0/9] ARM: Berlin: USB support
On Thu, Jun 05, 2014 at 05:48:37PM +0200, Antoine Ténart wrote: > This series adds the support for the Marvell Berlin USB controllers, > the USB PHYs and also adds a reset controller. > > The reset controller is used by the USB PHY driver and shares the > existing chip controller node with the clocks and one pin controller. > > The Marvell Berlin USB controllers are host only on the BG2Q and are > compatible with USB ChipIdea. We here add a glue to use the available > common functions for this kind of controllers. A USB PHY driver is also > added to control the PHY. > > Antoine Ténart (9): > reset: add the Berlin reset controller driver > ARM: Berlin: select the reset controller > ARM: dts: berlin: add a required reset property in the chip controller > node > usb: phy: add the Berlin USB PHY driver > Documentation: bindings: add doc for the Berlin USB PHY > usb: chipidea: add Berlin USB support > Documentation: bindings: add doc for the Berlin ChipIdea USB driver > ARM: dts: berlin: add BG2Q nodes for USB support > ARM: dts: Berlin: enable USB on the BG2Q DMP > > .../devicetree/bindings/usb/berlin-usbphy.txt | 18 ++ > .../devicetree/bindings/usb/ci-hdrc-berlin.txt | 18 ++ > arch/arm/boot/dts/berlin2.dtsi | 1 + > arch/arm/boot/dts/berlin2cd.dtsi | 1 + > arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 20 ++ > arch/arm/boot/dts/berlin2q.dtsi| 52 + > arch/arm/mach-berlin/Kconfig | 2 + > drivers/reset/Makefile | 1 + > drivers/reset/reset-berlin.c | 113 +++ > drivers/usb/chipidea/Makefile | 1 + > drivers/usb/chipidea/ci_hdrc_berlin.c | 108 ++ > drivers/usb/phy/Kconfig| 9 + > drivers/usb/phy/Makefile | 1 + > drivers/usb/phy/phy-berlin-usb.c | 223 > + > 14 files changed, 568 insertions(+) > create mode 100644 Documentation/devicetree/bindings/usb/berlin-usbphy.txt > create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-berlin.txt > create mode 100644 drivers/reset/reset-berlin.c > create mode 100644 drivers/usb/chipidea/ci_hdrc_berlin.c > create mode 100644 drivers/usb/phy/phy-berlin-usb.c > > -- > 1.9.1 > I am fine with 6/9, 7/9, will queue them if no other objections. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] delete unnecessary bootmem struct page array
Hi, Richard Any comment about this patch? thanks On Tue, Jun 03, 2014 at 01:30:44PM +0800, Real Name wrote: > From: Honggang Li > > The patch based on linux-next-2014-06-02. > > The old init_maps function does two things: > 1) allocates and initializes one struct page array for bootmem > 2) count the number of total pages > > After removed the source code related to the unnecessary array, the name > 'init_maps' is some kind of improper named, as it just count the number of > total page numbers. So, I renamed the function as 'mem_total_pages'. > > I tested the patch through repeat reboot the uml kernel many times. > [real@name linux-next]$ make ARCH=um defconfig > [real@name linux-next]$ make ARCH=um linux > [real@name linux-next]$ file linux > linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically > linked (uses shared libs), for GNU/Linux 2.6.32, not stripped > [real@name linux-next]$ ./linux > ubda=/home/real/linux-next/Fedora20-AMD64-root_fs mem=256m && sync && echo 1 > [real@name linux-next]$ ./linux > ubda=/home/real/linux-next/Fedora20-AMD64-root_fs mem=256m && sync && echo 2 > (repeat reboot the uml kernel many times..) > > Honggang Li (1): > delete unnecessary bootmem struct page array > > arch/um/include/shared/mem_user.h | 2 +- > arch/um/kernel/physmem.c | 32 ++-- > arch/um/kernel/um_arch.c | 7 +-- > 3 files changed, 8 insertions(+), 33 deletions(-) > > -- > 1.8.3.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove csum_partial_copy_generic_i386 to clean up exception table
On Thu, Jun 05, 2014 at 11:49:49PM +0200, Richard Weinberger wrote: > Am 05.06.2014 06:15, schrieb Honggang Li: > > arch/x86/um/checksum_32.S had been copy & paste from x86. When build > > x86 uml, csum_partial_copy_generic_i386 mess up the exception table. > > In fact, exception table dose not work in uml kernel. > > Are you sure that exception tables do not work on UML? > I said, I'm not sure. Can you please find out? I think we can't test the exception table with linux-next uml kernel, because the exception table is broken. The *old* linux-2.4.xx uml kernel has a good exception table. 1) install one redhat-9.0 virtual machine 2) build and booting into linux-2.4.25. You can't run uml kernel with default redhat-9.0 kernel, because there is one bug. 3) build linux-2.4.20 uml kernel (with uml-patch-2.4.20-8) 4) run linux-2.4.20/linux ubda=/root/root_fs.rh-7.2-server.pristine.20020312 mem=64m (The root_fs and uml-patch are available from the *old* uml website.) The exception table records of the old kernel belong to csum_partial_copy_generic_i386 too. # objjdump --full-contents --section=__ex_table arch/um/sys-i386/checksum.o arch/um/sys-i386/checksum.o: file format elf32-i386 Contents of section __ex_table: c700 cd00 1b00 0010 e400 e600 0020 eb00 1b00 ef00 1b00 0030 f200 f500 0040 fa00 1b00 ff00 1b00 0050 0201 0501 0060 0a01 1b00 0f01 1b00 0070 1201 1501 0080 1a01 1b00 1f01 1b00 0090 3c01 4001 1b00 <...@... 00a0 5801 5e01 1b00 X...^... 00b0 6901 6b01 1b00 i...k.. [root@rht9 linux-2.4.20]# objdump --full-contents --section=__ex_table arch/um/kern> arch/um/kernel/checksum.o: file format elf32-i386 [root@rht9 linux-2.4.20]# objdump --full-contents --section=__ex_table linux linux: file format elf32-i386 Contents of section __ex_table: a0203c20 5b680ea0 2cd31ba0 61680ea0 47d31ba0 [h..,...ah..G... a0203c30 78680ea0 2cd31ba0 7a680ea0 2cd31ba0 xh..,...zh..,... a0203c40 7f680ea0 47d31ba0 83680ea0 47d31ba0 .h..Gh..G... a0203c50 86680ea0 2cd31ba0 89680ea0 2cd31ba0 .h..,h..,... a0203c60 8e680ea0 47d31ba0 93680ea0 47d31ba0 .h..Gh..G... a0203c70 96680ea0 2cd31ba0 99680ea0 2cd31ba0 .h..,h..,... a0203c80 9e680ea0 47d31ba0 a3680ea0 47d31ba0 .h..Gh..G... a0203c90 a6680ea0 2cd31ba0 a9680ea0 2cd31ba0 .h..,h..,... a0203ca0 ae680ea0 47d31ba0 b3680ea0 47d31ba0 .h..Gh..G... a0203cb0 d0680ea0 2cd31ba0 d4680ea0 47d31ba0 .h..,h..G... a0203cc0 ec680ea0 2cd31ba0 f2680ea0 47d31ba0 .h..,h..G... a0203cd0 fd680ea0 2cd31ba0 ff680ea0 47d31ba0 .h..,h..G... ** The exception table of linux-3.1x.y is broken. The complier tool chain create bad exception table. I think this should be a bug. linux-3.12.6]$ objdump --full-contents --section=__ex_table ./linux ./linux: file format elf32-i386 Contents of section __ex_table: 82a5048 3e6fdcff bcbaf6ff 396fdcff b4baf6ff >o..9o.. 82a5058 336fdcff acbaf6ff 306fdcff bfbaf6ff 3o..0o.. 82a5068 2b6fdcff 9cbaf6ff 286fdcff afbaf6ff +o..(o.. 82a5078 236fdcff 8cbaf6ff 206fdcff 9fbaf6ff #o.. o.. 82a5088 1b6fdcff 7cbaf6ff 186fdcff 8fbaf6ff .o..|o.. 82a5098 136fdcff 6cbaf6ff 106fdcff 7fbaf6ff .o..lo.. 82a50a8 0b6fdcff 5cbaf6ff 086fdcff 6fbaf6ff .o..\o..o... 82a50b8 036fdcff 4cbaf6ff 006fdcff 5fbaf6ff .o..Lo.._... 82a50c8 fb6edcff 3cbaf6ff f86edcff 4fbaf6ff .n..> In arch/um/kernel/trap.c:segv() we have the mechanism for it: > else if (!is_user && arch_fixup(ip, regs)) > goto out; > The kcov analysis proof that this piece of code never been executed. > The interesting question is, is this by design or was it just copy > from x86 > many moons ago? :) Hi, Jeff Could you please answer this question, as you are the author? thanks > > > And
[PATCH] perf record: Fix to honor user freq/interval properly
When configuring event perf checked a wrong condition that user
specified both of freq (-F) and period (-c) or the event has no
default value. This worked because most of events don't have default
value and only tracepoint events have default of 1 (and it's not
desirable to change it for those events).
However, Andi's downloadable event patch changes the situation so it
cannot change the value for those events. Fix it by allowing override
the default value if user gives one of the options.
$ perf record -a -e uops_retired.all -F 4000 sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.325 MB perf.data (~14185 samples) ]
$ perf evlist -F
cpu/uops_retired.all/: sample_freq=4000
Cc: Andi Kleen
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/evsel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 5c28d82b76c4..5ff811c67adc 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -589,10 +589,10 @@ void perf_evsel__config(struct perf_evsel *evsel, struct
record_opts *opts)
}
/*
-* We default some events to a 1 default interval. But keep
+* We default some events to have a default interval. But keep
* it a weak assumption overridable by the user.
*/
- if (!attr->sample_period || (opts->user_freq != UINT_MAX &&
+ if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
opts->user_interval != ULLONG_MAX)) {
if (opts->freq) {
perf_evsel__set_sample_bit(evsel, PERIOD);
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
On 06/09/14 at 10:11am, Dave Young wrote:
> On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> > On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > > Previous patch provided the interface definition and this patch prvides
> > > > implementation of new syscall.
> > > >
> > > > Previously segment list was prepared in user space. Now user space just
> > > > passes kernel fd, initrd fd and command line and kernel will create a
> > > > segment list internally.
> > > >
> > > > This patch contains generic part of the code. Actual segment preparation
> > > > and loading is done by arch and image specific loader. Which comes in
> > > > next patch.
> > > >
> > > > Signed-off-by: Vivek Goyal
> > >
> > > [..]
> > > > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > > > index a3044e6..1ad4d60 100644
> > > > --- a/kernel/kexec.c
> > > > +++ b/kernel/kexec.c
> > >
> > > > +static int kimage_file_prepare_segments(struct kimage *image, int
> > > > kernel_fd,
> > > > + int initrd_fd, const char __user *cmdline_ptr,
> > > > + unsigned long cmdline_len)
> > > > +{
> > > > + int ret = 0;
> > > > + void *ldata;
> > > > +
> > > > + ret = copy_file_from_fd(kernel_fd, >kernel_buf,
> > > > + >kernel_buf_len);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + /* Call arch image probe handlers */
> > > > + ret = arch_kexec_kernel_image_probe(image, image->kernel_buf,
> > > > + image->kernel_buf_len);
> > > > +
> > > > + if (ret)
> > > > + goto out;
> > > > +
> > > > + ret = copy_file_from_fd(initrd_fd, >initrd_buf,
> > > > + >initrd_buf_len);
> > > > + if (ret)
> > > > + goto out;
> > > > +
> > > > + image->cmdline_buf = vzalloc(cmdline_len);
> > >
> > > You should validate the upper/lower boundary of cmdline_len before
> > > calling vzalloc. When cmdline_len is 0 or too large, vmalloc failure
> > > message would be fired.
> >
> > What's the upper length of vzalloc(). I think if it is too big to alloc,
> > then vzalloc() should return me an error?
When allocating too large, eg. vzalloc(-1), kernel spits:
[ 457.407579] vmalloc: allocation failure: 18446744073709551606 bytes
[ 457.413854] kexec: page allocation failure: order:0, mode:0x80d2
[ 457.419853] CPU: 3 PID: 2058 Comm: kexec Not tainted
3.15.0-rc8-00096-g3dc85e8 #10
[ 457.427408] Hardware name: Dell Inc. OptiPlex 760
/0M860N, BIOS A12 05/23/2011
[ 457.435999] 81a2f678 8800bfb03db0 816944fd
80d2
[ 457.443422] 8800bfb03e38 8118a31a 81a2f678
8800bfb03dd0
[ 457.450851] 88010018 8800bfb03e48 8800bfb03de8
8800bfb03e10
[ 457.458278] Call Trace:
[ 457.460731] [] dump_stack+0x45/0x56
[ 457.465865] [] warn_alloc_failed+0xda/0x140
[ 457.471693] [] ? kernel_read+0x41/0x60
[ 457.477085] [] __vmalloc_node_range+0x1b6/0x270
[ 457.483256] [] vzalloc+0x4b/0x50
[ 457.488132] [] ?
kimage_file_prepare_segments.part.10+0x85/0x140
[ 457.495774] []
kimage_file_prepare_segments.part.10+0x85/0x140
[ 457.503244] [] SyS_kexec_file_load+0x38a/0x690
[ 457.509330] [] system_call_fastpath+0x16/0x1b
[..]
I think it's better to do some sane check to prevent such warning when
taking arbitrary argument from user space.
>
> function __vmalloc_node_range:
> if (!size || (size >> PAGE_SHIFT) > totalram_pages)
> goto fail;
>
> So I think only checking cmdline_len == 0 is enough.
>
> For the upper length shouldn't it be stripped to COMMAND_LINE_SIZE?
Yes, COMMAND_LINE_SIZE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: governor: remove copy_prev_load from 'struct cpu_dbs_common_info'
'copy_prev_load' was recently added by commit: 18b46ab (cpufreq: governor: Be
friendly towards latency-sensitive bursty workloads).
It actually is a bit redundant as we also have 'prev_load' which can store any
integer value and can be used instead of 'copy_prev_load' by setting it to zero
when we don't want to use previous load.
So, drop 'copy_prev_load' and use 'prev_load' instead.
Update comments as well to make it more clear.
There is another change here which was probably missed by Srivatsa during the
last version of updates he made. The unlikely in the 'if' statement was covering
only half of the condition and the whole line should actually come under it.
Also checkpatch is made more silent as it was reporting this (--strict option):
CHECK: Alignment should match open parenthesis
+ if (unlikely(wall_time > (2 * sampling_rate) &&
+ j_cdbs->prev_load)) {
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_governor.c | 13 -
drivers/cpufreq/cpufreq_governor.h | 8
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 9004450..a1ad804 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -132,14 +132,18 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
* an unusually large 'wall_time' (as compared to the sampling
* rate) indicates this scenario.
*/
- if (unlikely(wall_time > (2 * sampling_rate)) &&
- j_cdbs->copy_prev_load) {
+ if (unlikely(wall_time > (2 * sampling_rate) &&
+j_cdbs->prev_load)) {
load = j_cdbs->prev_load;
- j_cdbs->copy_prev_load = false;
+
+ /*
+* Ensure that we copy the previous load only once, upon
+* the first wake-up from idle.
+*/
+ j_cdbs->prev_load = 0;
} else {
load = 100 * (wall_time - idle_time) / wall_time;
j_cdbs->prev_load = load;
- j_cdbs->copy_prev_load = true;
}
if (load > max_load)
@@ -373,7 +377,6 @@ int cpufreq_governor_dbs(struct cpufreq_policy *policy,
(j_cdbs->prev_cpu_wall - j_cdbs->prev_cpu_idle);
j_cdbs->prev_load = 100 * prev_load /
(unsigned int) j_cdbs->prev_cpu_wall;
- j_cdbs->copy_prev_load = true;
if (ignore_nice)
j_cdbs->prev_cpu_nice =
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index c2a5b7e..d3082ee 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -134,12 +134,12 @@ struct cpu_dbs_common_info {
u64 prev_cpu_idle;
u64 prev_cpu_wall;
u64 prev_cpu_nice;
- unsigned int prev_load;
/*
-* Flag to ensure that we copy the previous load only once, upon the
-* first wake-up from idle.
+* Used to store system load before going into idle, when set to zero:
+* used as a flag to ensure that we copy the previous load only once,
+* upon the first wake-up from idle.
*/
- bool copy_prev_load;
+ unsigned int prev_load;
struct cpufreq_policy *cur_policy;
struct delayed_work work;
/*
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9] perf, tools, record: Always allow to overide default period v2
On Wed, 4 Jun 2014 09:59:30 -0700, Andi Kleen wrote: > I saw samples. > > Oh well we can just drop it. The only difference is that the > event list cannot set a period then. I tested with a downloaded event, and it does have samples. But the frequency could not be changed even with your patch. $ perf record -a -e uops_retired.all -F 4000 sleep 1 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.327 MB perf.data (~14281 samples) ] $ perf evlist -F cpu/uops_retired.all/: sample_freq=203 > > It's as broken as before. At least, it worked well for events don't have a default sample freq/period which means all but tracepoint events. For tracepoint events, it makes little sense to change the default so I decided not to touch it. But with your change, the downloaded events might have a default freq/period setting now. So I'd like to make it right. I'll send a fix for this right soon. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression] commit 8a4aeec8d(libata/ahci: accommodate tag ordered controllers)
Hi Suman, On Sun, Jun 8, 2014 at 12:51 PM, Suman Tripathi wrote: > Hi Ming, > > I have attached the patches but it is not accepted by Tejun yet, So I will > post another version. OK, thanks. Since Tejun didn't think it is a workable approach, I am not going test the attachment, but I will look at / test your next version. Also, Loc mentioned that only your early chip has the problem, I am wondering why you don't take Dan's approach just for the affected chips? Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/05] staging: Emma Mobile USB driver and KZM9D board code V3
On Sat, Jun 7, 2014 at 12:39 AM, Greg KH wrote: > On Fri, Jun 06, 2014 at 07:44:08PM +0900, Magnus Damm wrote: >> staging: Emma Mobile USB driver and KZM9D board code V3 >> >> [PATCH v3 01/05] staging: emxx_udc: Add Emma Mobile USB Gadget driver >> [PATCH v3 02/05] staging: emxx_udc: I/O memory and IRQ resource support >> [PATCH v3 03/05] staging: emxx_udc: Add TODO file >> [PATCH v3 04/05] staging: board: Initial board staging support >> [PATCH v3 05/05] staging: board: kzm9d: Board staging support for emxx_udc >> >> This patch series is V3 of the old USB Gadget driver for Emma Mobile >> that gets slightly adjusted to make use of the platform device interface >> which in turn is used to add USB Gadget support to the KZM9D board. >> >> Two separate staging components are included in this series: >> 1) the emxx_udc driver - from out-of-tree Android 2.6.35.7 >> 2) board staging support for KZM9D - platform device for DT-only KZM9D >> >> The two components above will be used to continously improve the driver >> and board integration code until the driver can be moved out of staging >> and/or DT bindings are available so the board staging platform device code >> can be replaced with a DT node. >> >> Changes since V2: >> - Added CONFIG_OF_ADDRESS dependency for the board staging bits >> >> Changes since V1: >> - Added TODO file for emxx_udc >> - Broke out board staging base support, included TODO file >> - Added code to avoid registering platform device if DT node exists >> - Modified KZM9D board code build condition to use SoC Kconfig entry >> >> Many thanks to Dan Carpenter, Geert Uytterhoeven, Greg KH and >> Paul Bolle for feedback! >> >> Please let me know if you would like me to rebase this code somehow. > > At quick glance, this looks good. I'll queue it up after 3.16-rc1 is > out as it's too late for this merge window. Thanks, Greg! This sounds perfect to me! Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
On 8 June 2014 02:11, Srivatsa S. Bhat wrote:
> diff --git a/drivers/cpufreq/cpufreq_governor.c
> b/drivers/cpufreq/cpufreq_governor.c
> + if (unlikely(wall_time > (2 * sampling_rate)) &&
> + j_cdbs->copy_prev_load) {
> + load = j_cdbs->prev_load;
> + j_cdbs->copy_prev_load = false;
> + } else {
> + load = 100 * (wall_time - idle_time) / wall_time;
> + j_cdbs->prev_load = load;
> + j_cdbs->copy_prev_load = true;
> + }
Hmm, slight modifications over the weekend :) ..
What do you think about removing this extra variable and using prev_load
only, i.e. make it zero in the else part? Also adding a comment for this would
be helpful ?
I will try a patch before you come to office :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Question] Why CONFIG_SHELL
Hi experts. I think all the macros with CONFIG_ prefix are supposed to be defined in Kconfig. But I've been long wondering why there exists one exception: CONFIG_SHELL. Is there any historical, or special reason? Is it good to rename it to KBUILD_SHELL or something else? Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] perf, tools: Add support for text descriptions of events and alias add
Hi Andi,
On Fri, 30 May 2014 14:50:08 -0700, Andi Kleen wrote:
> @@ -756,22 +816,31 @@ void print_pmu_events(const char *event_glob, bool
> name_only)
> (!is_cpu && strglobmatch(alias->name,
> event_glob
> continue;
> - aliases[j] = name;
> - if (is_cpu && !name_only)
> - aliases[j] = format_alias_or(buf, sizeof(buf),
> - pmu, alias);
> - aliases[j] = strdup(aliases[j]);
> + aliases[j].name = name;
> + if (is_cpu && !name_only && !alias->desc)
> + aliases[j].name = format_alias_or(buf,
> + sizeof(buf),
> + pmu, alias);
> + aliases[j].name = strdup(aliases[j].name);
> + aliases[j].desc = alias->desc;
> j++;
> }
> len = j;
> - qsort(aliases, len, sizeof(char *), cmp_string);
> + qsort(aliases, len, sizeof(struct pair), cmp_pair);
> for (j = 0; j < len; j++) {
> if (name_only) {
> - printf("%s ", aliases[j]);
> + printf("%s ", aliases[j].name);
> continue;
> }
> - printf(" %-50s [Kernel PMU event]\n", aliases[j]);
> - zfree([j]);
> + if (aliases[j].desc) {
> + if (numdesc++ == 0 && printed)
> + printf("\n");
> + printf(" %-50s [", aliases[j].name);
> + wordwrap(aliases[j].desc, 53, columns, 1);
> + printf("]\n");
> + } else
> + printf(" %-50s [Kernel PMU event]\n", aliases[j].name);
> + zfree([j].name);
Hmm.. this will print the description at right side and I think it'd be
better if it prints in another line(s) like below:
agu_bypass_cancel.count[Kernel PMU event]
This event counts executed load operations with all the following
traits: 1. addressing of the format [base + offset], 2. the offset
is between 1 and 2047, 3. the address specified in the base register
is in one page and the address [base+offset] is in an
arith.fpu_div [Kernel PMU event]
Divide operations executed
arith.fpu_div_active [Kernel PMU event]
Cycles when divider is busy executing divide operations
...
I just tweaked it using -v option for perf list. Below is the change I
made on top of your series. What do you think?
Thanks,
Namhyung
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 086c96fa959b..e65a3b428a44 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -13,6 +13,7 @@
#include "util/parse-events.h"
#include "util/cache.h"
+#include "util/debug.h"
#include "util/pmu.h"
#include "util/parse-options.h"
@@ -22,6 +23,8 @@ int cmd_list(int argc, const char **argv, const char *prefix
__maybe_unused)
const struct option list_options[] = {
OPT_STRING(0, "events-file", _file, "json file",
"Read event json file"),
+ OPT_INCR('v', "verbose", ,
+"be more verbose (show event description if exist)"),
OPT_END()
};
const char * const list_usage[] = {
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index b87f52058bb4..99a2156e6c54 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -838,14 +838,16 @@ void print_pmu_events(const char *event_glob, bool
name_only)
printf("%s ", aliases[j].name);
continue;
}
- if (aliases[j].desc) {
- if (numdesc++ == 0 && printed)
- printf("\n");
- printf(" %-50s [", aliases[j].name);
- wordwrap(aliases[j].desc, 53, columns, 1);
- printf("]\n");
- } else
- printf(" %-50s [Kernel PMU event]\n", aliases[j].name);
+
+ if (aliases[j].desc && numdesc++ == 0 && printed)
+ printf("\n");
+ printf(" %-50s [Kernel PMU event]\n", aliases[j].name);
+
+ if (aliases[j].desc && verbose) {
+ printf("%8s", "");
+ wordwrap(aliases[j].desc, 8, columns, 1);
+ printf("\n");
+ }
zfree([j].name);
printed++;
}
--
To unsubscribe from this list: send the
Re: [PATCH v6] NVMe: conversion to blk-mq
On Fri, Jun 6, 2014 at 8:20 PM, Matias Bjørling wrote: > This converts the current NVMe driver to utilize the blk-mq layer. Looks it can't be applied cleanly against 3.15-rc8 + Jens's for-linux branch, when I fix the conflict manually, below failure is triggered: [ 487.696057] nvme :00:07.0: Cancelling I/O 202 QID 1 [ 487.699005] nvme :00:07.0: Aborting I/O 202 QID 1 [ 487.704074] nvme :00:07.0: Cancelling I/O 202 QID 1 [ 487.717881] nvme :00:07.0: Aborting I/O 202 QID 1 [ 487.736093] end_request: I/O error, dev nvme0n1, sector 91532352 [ 487.747378] nvme :00:07.0: completed id 0 twice on queue 0 when running fio randread(libaio, iodepth:64) with more than 3 jobs. And looks no such failure when jobs is 1 or 2. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: warn on unnecessary else after return or break
Using an else following a break or return can unnecessarily
indent code blocks.
ie:
for (i = 0; i < 100; i++) {
int foo = bar();
if (foo < 1)
break;
else
usleep(1);
}
is generally better written as:
for (i = 0; i < 100; i++) {
int foo = bar();
if (foo < 1)
break;
usleep(1);
}
Warn when a bare else statement is preceded by a
break or return indented 1 tab more than the else.
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 10 ++
1 file changed, 10 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 010b18e..9059fd0 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2342,6 +2342,16 @@ sub process {
# check we are in a valid C source file if not then ignore this hunk
next if ($realfile !~ /\.(h|c)$/);
+# check indentation of any line with a bare else
+# if the previous line is a break or return and is indented 1 tab more...
+ if ($sline =~ /^\+([\t]+)(?:}[ \t]*)?else(?:[ \t]*{)?\s*$/) {
+ my $tabs = length($1) + 1;
+ if ($prevline =~
/^\+\t{$tabs,$tabs}(?:break|return)\b/) {
+ WARN("UNNECESSARY_ELSE",
+"else is not generally useful after a
break or return\n" . $hereprev);
+ }
+ }
+
# discourage the addition of CONFIG_EXPERIMENTAL in #if(def).
if ($line =~ /^\+\s*\#\s*if.*\bCONFIG_EXPERIMENTAL\b/) {
WARN("CONFIG_EXPERIMENTAL",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?
Sigh, adventures in "unable to mount root filesystem" currently underway. Tested on a different computer without patches (half size, since it's an older machine): Writing 16 MiB: 16777216 bytes (17 MB) copied, 0.289169 s, 58.0 MB/s 16777216 bytes (17 MB) copied, 0.289378 s, 58.0 MB/s Writing while reading: 16777216 bytes (17 MB) copied, 0.538839 s, 31.1 MB/s 4194304 bytes (4.2 MB) copied, 0.544769 s, 7.7 MB/s 16777216 bytes (17 MB) copied, 0.537425 s, 31.2 MB/s 4194304 bytes (4.2 MB) copied, 0.544259 s, 7.7 MB/s 16777216 bytes (17 MB) copied, 0.740495 s, 22.7 MB/s 4194304 bytes (4.2 MB) copied, 0.879353 s, 4.8 MB/s 4194304 bytes (4.2 MB) copied, 0.879629 s, 4.8 MB/s 16777216 bytes (17 MB) copied, 0.7262 s, 23.1 MB/s 4194304 bytes (4.2 MB) copied, 0.877035 s, 4.8 MB/s 4194304 bytes (4.2 MB) copied, 0.880627 s, 4.8 MB/s 16777216 bytes (17 MB) copied, 0.996933 s, 16.8 MB/s 4194304 bytes (4.2 MB) copied, 1.24551 s, 3.4 MB/s 4194304 bytes (4.2 MB) copied, 1.26138 s, 3.3 MB/s 4194304 bytes (4.2 MB) copied, 1.2664 s, 3.3 MB/s 16777216 bytes (17 MB) copied, 0.969144 s, 17.3 MB/s 4194304 bytes (4.2 MB) copied, 1.25311 s, 3.3 MB/s 4194304 bytes (4.2 MB) copied, 1.26076 s, 3.3 MB/s 4194304 bytes (4.2 MB) copied, 1.25887 s, 3.3 MB/s Summarized: 0 readers: 0.289169 0.289378 1 reader: 0.538839 0.537425(+86%) 2 readers: 0.740495 0.726200(+153%) 3 readers: 0.996933 0.969144(+240%) That seems... noticeable. Causing iterrupt latency problems is defintiely a theoretical extrapolation, however. For comparison, on this system, dd from /dev/zero runs at 1 GB/s per thread for up to 4 threads with no interference. *Really* confusingly, dd from /dev/zero to tmpfs runs at 450 MB/s (per thread) for 2 to 4 threads, but 325 MB/s for 1 thread. NFclue. (This is writing to separate files; writing the the same file is slower.) dd from tmpfs to tmpfs runs at about 380 MB/s, again independent of the number of threads up to the number of CPUs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] phy: Add provision for calibrating phy.
On Fri, Jun 06, 2014 at 08:12:12PM +0800, Vivek Gautam wrote: > Some PHY controllers may need to calibrate certain > PHY settings after initialization of the controller and > sometimes even after initializing the PHY-consumer too. > Add support for the same in order to let consumers do so in need. > > Signed-off-by: vivek Gautam > --- > drivers/phy/phy-core.c | 36 > include/linux/phy/phy.h |7 +++ > 2 files changed, 43 insertions(+) > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index 74d4346..92d31a3 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -376,6 +376,42 @@ int phy_power_off(struct phy *phy) > EXPORT_SYMBOL_GPL(phy_power_off); > > /** > + * phy_calibrate - calibrate a phy post initialization > + * @phy: Pointer to 'phy' from consumer > + * > + * For certain PHYs, it may be needed to calibrate few phy parameters > + * post initialization. The need to calibrate may arise after the For USB you may need to calibrate phy after each new connection. If so, why not to use already existing struct usb_phy's notify_connect. pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: Add a defer reset object to send board specific reset
# RESEND and please ignore previous mail #
On 2014/06/08 20:58, Alexandre Courbot wrote:
> Interesting approach to a long-standing problem. I had my own
> embarrassing attempt at it (power sequences), and more recently Olof
> (CC'd) sent something related for the MMC bus
> (http://www.spinics.net/lists/devicetree/msg18900.html - I'm not sure
> what has become of this patch?). And there are certainly other
> attempts that I don't know of. So, let's say that this time we do it
> for real. There are some points I like in your approach, like the fact
> that it is completely bus-agnostic. But although it will certainly not
> end up being as controversial as the power sequences have been, I am
> not sure everybody will agree to use the DT this way...
Thanks a lot for your reply. I not sure if DT people like this approach to use
DT. As most poeple use DT as a script to describe a hardware board: cpu,
buses, memory, address mappings and devices. But I think the DT file can also
be a interface between hardware and software engineers. From the software
engineer's view to a board, he may not get clear informed that this board's
some chip need a special reset signal when bus is on. From the hardware
engineer's view, every devices may works well on bootloader but not in Linux.
The DT file can serve as note between the two engineers, and a defered reset
object specify in DT file level can a useful note in this situation.
>> Example dts File
>>
>> usb-ehci-chip@1211000{
>> usb-phy = <_phy>;
>> defer_reset_vbus {
>> compatible = "defer-reset";
>> reset-gpios = < 5 1>;
>> reset-init = <0>;
>> reset-end = <1>;
>> delay = <5>;
>> };
>> };
>
> Here I am not convinced that everybody will like the fact that this
> appears as a device of its own, with its own compatible property.
> Let's see what the DT people think of it.
Yes, this patch need DT people agree to use DT in this way.
>
> + /* setup parameters */
> + of_property_read_u32_array(dnode, "reset-init", reset_init, count);
> + of_property_read_u32_array(dnode, "reset-end", reset_end, count);
> + of_property_read_u32(dnode, "delay", );
> +
> + /* reset init */
> + for (i = 0; i < count; i++) {
> + gpio = of_get_named_gpio(dnode, "reset-gpios", i);
>
> Quick note: please make use of the gpiod interface in your code.
> (include/linux/gpio/consumer.h and Documentation/gpio/consumer.txt).
> That will simplify it a great deal and will force you to actually
> request the GPIOs, which you omitted here.
I ommitted this and will add code to use consumer.h in next version.
> +static int gdr_probe(struct platform_device *pdev)
> +{
> + struct list_head *pos;
> +
> + pr_debug("gpio defer reset probe\n");
> + list_for_each(pos, _reset_list) {
> + struct platform_device *pd;
> + struct defer_reset_private *prv = list_entry(
> + pos, struct defer_reset_private, next);
> + if (prv->issued)
> + continue;
> + pd = of_find_device_by_node(
> + prv->node->parent);
> + if (pd->dev.driver != 0) {
> + gdr_issue_reset(pdev, prv->node);
> + prv->issued = 1;
>
> Is there anything that prevents you from removing (and freeing) the
> items from the list once the reset is issued?
Nothing prevents the removing and freeing. The resources claimed by this
driver are no depend to others and should be release immediately after usage.
The free of resources will be added in next version.
>
>
>> + }
>> + }
>> + list_for_each(pos, _reset_list) {
>> + struct defer_reset_private *prv = list_entry(pos,
>> + struct defer_reset_private, next);
>> + if (!prv->issued)
>> + return -EPROBE_DEFER;
>> + }
>> + return 0;
>
> If you can remove your defer_reset_private instances as they are
> processed you can simple return 0 if the list is empty, or
> -EPROBE_DEFER otherwise. And probably get rid of your "issued" member
> too.
>
> Also, once everything is processed, it would be nice to de-register your
> device.
Yes, the driver only need a list to keep all pending deferred reset. Once
a reset is issued, the corresponding deferred-reset object in list can be
removed and that the member "issued" can no longer needed. When list empty,
de-register this device from kernel.
>
> Before doing a more thorough review, I'd like to discuss the basic
> idea. All the previous attempts at implementing an out-of-bus reset
> mechanism are strong evidence that something like this is needed.
> Having a generic mechanism would be a great plus. I am not convinced
> that using a dummy device instance is the right thing to do though.
> Also depending on the bus or device you might
Re: Linux 3.15 .. and continuation of merge window
Linus Torvalds: > So I ended up doing an rc8 because I was a bit worried about some > last-minute dcache fixes, but it turns out that nobody seemed to even > notice those. We did have other issues during the week, though, so it ::: I am afraid there is a problem in dcache. Please read http://marc.info/?l=linux-fsdevel=140214911608925=2 For 3.16, please consider these patches. - for vfs [PATCH v2] vfs: get_next_ino(), never inum=0 http://marc.info/?l=linux-fsdevel=140128600801771=2 - for tmpfs [RFC PATCH v4 0/2] tmpfs: manage the inode-number by IDR (performance measure) http://marc.info/?l=linux-fsdevel=140197128021025=2 [RFC PATCH v4 1/2] tmpfs: manage the inode-number by IDR, signed int inum http://marc.info/?l=linux-fsdevel=140197128321029=2 [RFC PATCH v4 2/2] tmpfs: refine a file handle for NFS-exporting http://marc.info/?l=linux-fsdevel=140197128121026=2 J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rt/aio: fix rcu garbage collection might_sleep() splat
On Mon, 2014-06-09 at 10:08 +0800, Lai Jiangshan wrote: > Hi, rt-people > > I don't think it is the correct direction. Yup, it's a band-aid, ergo RFC. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?
> Summarizing that, time to feed in 32 MiB of zeros (from user-space): > > 0 concurrent reads: 0.356898 0.357693 > 1 concurrent read: 0.505941 0.509075(+42%) > 2 concurrent reads: 0.662240 0.657055(+84%) Er, wait a minute... I'm not sure which kernel (patched or unpatched) I did that measurement on. That may be a completely useless number. I need to compile some more kernels and reboot a few more times. Sorry about that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: imx6: add missing compatible and clock properties for kpp
On Fri, Jun 06, 2014 at 01:02:59PM +0200, Lothar Waßmann wrote:
>
> Signed-off-by: Lothar Waßmann
> ---
> arch/arm/boot/dts/imx6qdl.dtsi |2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
Shawn
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index ce05991..3266d01 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -466,8 +466,10 @@
> };
>
> kpp: kpp@020b8000 {
> + compatible = "fsl,imx6q-kpp", "fsl,imx21-kpp";
> reg = <0x020b8000 0x4000>;
> interrupts = <0 82 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < 62>; /* IPG clock */
> };
>
> wdog1: wdog@020bc000 {
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] drivers/base: Fix length checks in create_syslog_header()/dev_vprintk_emit()
On Sun, 2014-06-08 at 23:51 +0100, Ben Hutchings wrote: > snprintf() returns the number of bytes that could have been written > (excluding the null), not the actual number of bytes written. Given a > long enough subsystem or device name, these functions will advance > beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting > in an information leak or stack corruption. I don't know whether such > a long name is currently possible. > In case snprintf() returns a value >= the buffer size, do not add > structured logging information. I believe this is guaranteed to be < 128, but I also suppose it'd be better to emit whatever buffer is < 128 and add a WARN_ON_ONCE instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dt/documentation: add specification of dma bus information
On Thu, Jun 5, 2014 at 12:22 PM, Santosh Shilimkar wrote: > Recently we introduced the generic device tree infrastructure for couple of > DMA > bus parameter, dma-ranges and dma-coherent. Update the documentation so that > its useful for future users. > > The "dma-ranges" property is intended to be used for describing the > configuration of DMA bus RAM addresses and its offset w.r.t CPU addresses. > > The "dma-coherent" property is intended to be used for identifying devices > supported coherent DMA operations. > > Cc: Arnd Bergmann > Cc: Grant Likely > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Shawn Guo > Cc: Kumar Gala > Signed-off-by: Grygorii Strashko > Signed-off-by: Santosh Shilimkar > --- > Documentation/devicetree/booting-without-of.txt | 60 > +++ > 1 file changed, 60 insertions(+) > > diff --git a/Documentation/devicetree/booting-without-of.txt > b/Documentation/devicetree/booting-without-of.txt > index 1f013bd..f0120c1 100644 > --- a/Documentation/devicetree/booting-without-of.txt > +++ b/Documentation/devicetree/booting-without-of.txt > @@ -51,6 +51,8 @@ Table of Contents > >VIII - Specifying device power management information (sleep property) > > + VIV - Specifying dma bus information "9" in Roman numeral is "IX" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?
> Which writer are you worried about, specifically? A userspace write > to /dev/random from rgnd? Actually, the part I'm actually worried about is latency in add_interrupt_randomness. But I may have not understood how the locking works. There's a per-CPU fast pool which isn't locked at all, which feeds the input_pool, and the add to the input pool would be slow if it were locked, but it seems hard for user space to force a lot of locking activity on the input_pool. A bulk read will drain the secondary pool, but random_min_urandom_seed will prevent reseeding, so lock contention on input_pool will be almost nil. Maybe I need to turn this into a documentation patch explaining all of this. > And have you measured this to be something significant, or is this a > theoretical concern. If you've measured it, what's the conditions > where this is stalling an entropy mixer a significant amount of time? It's a theoretical extrapolation from timing of user-space writes. Some time comparisons (on a multicore machine so the two threads should run on separate processors, and with scaling_governor = performance): $ dd if=/dev/zero of=/dev/random count=65536 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.356898 s, 94.0 MB/s $ dd if=/dev/zero of=/dev/random count=65536 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.357693 s, 93.8 MB/s $ dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/zero of=/dev/random count=65536 ; sleep 4 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.505941 s, 66.3 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.715132 s, 11.7 MB/s $ dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/zero of=/dev/random count=65536 ; sleep 4 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.509075 s, 65.9 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.734479 s, 11.4 MB/s $ dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/zero of=/dev/random count=65536 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.66224 s, 50.7 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.894693 s, 9.4 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.895628 s, 9.4 MB/s $ dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/urandom of=/dev/null count=16384 & dd if=/dev/zero of=/dev/random count=65536 ; sleep 4 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 0.657055 s, 51.1 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.908407 s, 9.2 MB/s 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB) copied, 0.908989 s, 9.2 MB/s Summarizing that, time to feed in 32 MiB of zeros (from user-space): 0 concurrent reads: 0.356898 0.357693 1 concurrent read: 0.505941 0.509075 (+42%) 2 concurrent reads: 0.662240 0.657055 (+84%) ... so it seems like there are some noticeable contention effects. And then I started thinking, and realized that the out[] parameter wasn't doing anything useful at all, and even if we don't change anything else at all, maybe it should be deleted and de-clutter the code? It dates back to the days when entropy adding tried to be lockless, but that was a long time ago. And once you have locking, it no longer serves any function. It's a bit of meandering stream of consciousness, sorry. The latency issue is where I started, but the general uselessness of out[] is what I felt really needed discussing before I proposed a patch to dike it out. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/13] kexec: Implementation of new syscall kexec_file_load
On 06/06/14 at 02:19pm, Vivek Goyal wrote:
> On Fri, Jun 06, 2014 at 02:56:05PM +0800, WANG Chao wrote:
> > On 06/03/14 at 09:06am, Vivek Goyal wrote:
> > > Previous patch provided the interface definition and this patch prvides
> > > implementation of new syscall.
> > >
> > > Previously segment list was prepared in user space. Now user space just
> > > passes kernel fd, initrd fd and command line and kernel will create a
> > > segment list internally.
> > >
> > > This patch contains generic part of the code. Actual segment preparation
> > > and loading is done by arch and image specific loader. Which comes in
> > > next patch.
> > >
> > > Signed-off-by: Vivek Goyal
> >
> > [..]
> > > diff --git a/kernel/kexec.c b/kernel/kexec.c
> > > index a3044e6..1ad4d60 100644
> > > --- a/kernel/kexec.c
> > > +++ b/kernel/kexec.c
> >
> > > +static int kimage_file_prepare_segments(struct kimage *image, int
> > > kernel_fd,
> > > + int initrd_fd, const char __user *cmdline_ptr,
> > > + unsigned long cmdline_len)
> > > +{
> > > + int ret = 0;
> > > + void *ldata;
> > > +
> > > + ret = copy_file_from_fd(kernel_fd, >kernel_buf,
> > > + >kernel_buf_len);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Call arch image probe handlers */
> > > + ret = arch_kexec_kernel_image_probe(image, image->kernel_buf,
> > > + image->kernel_buf_len);
> > > +
> > > + if (ret)
> > > + goto out;
> > > +
> > > + ret = copy_file_from_fd(initrd_fd, >initrd_buf,
> > > + >initrd_buf_len);
> > > + if (ret)
> > > + goto out;
> > > +
> > > + image->cmdline_buf = vzalloc(cmdline_len);
> >
> > You should validate the upper/lower boundary of cmdline_len before
> > calling vzalloc. When cmdline_len is 0 or too large, vmalloc failure
> > message would be fired.
>
> What's the upper length of vzalloc(). I think if it is too big to alloc,
> then vzalloc() should return me an error?
function __vmalloc_node_range:
if (!size || (size >> PAGE_SHIFT) > totalram_pages)
goto fail;
So I think only checking cmdline_len == 0 is enough.
For the upper length shouldn't it be stripped to COMMAND_LINE_SIZE?
> > > + if (!image->cmdline_buf)
> > > + goto out;
> > > +
> > > + ret = copy_from_user(image->cmdline_buf, cmdline_ptr, cmdline_len);
> > > + if (ret) {
> > > + ret = -EFAULT;
> > > + goto out;
> > > + }
> > > +
> > > + image->cmdline_buf_len = cmdline_len;
> > > +
> > > + /* command line should be a string with last byte null */
> > > + if (image->cmdline_buf[cmdline_len - 1] != '\0') {
> > > + ret = -EINVAL;
> > > + goto out;
> > > + }
> >
> > Given the fact that command line is optional as well as initrd, I think
> > above chunk of code needs to update a bit for the case cmdline_len is 0
> > or cmdline_buf is pointing NULL?
>
> I agree. I think all this vzalloc(), copy_from_user() etc should be called
> only fir cmdline_len is non-zero. Will fix it.
>
> Thanks
> Vivek
>
>
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dt/documentation: add specification of dma bus information
On Thu, Jun 05, 2014 at 11:22:00AM -0400, Santosh Shilimkar wrote: > Recently we introduced the generic device tree infrastructure for couple of > DMA > bus parameter, dma-ranges and dma-coherent. Update the documentation so that > its useful for future users. > > The "dma-ranges" property is intended to be used for describing the > configuration of DMA bus RAM addresses and its offset w.r.t CPU addresses. > > The "dma-coherent" property is intended to be used for identifying devices > supported coherent DMA operations. > > Cc: Arnd Bergmann > Cc: Grant Likely > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Shawn Guo > Cc: Kumar Gala > Signed-off-by: Grygorii Strashko > Signed-off-by: Santosh Shilimkar Thanks for the documentation. I think it's definitely useful for future users of the binding. Acked-by: Shawn Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] rt/aio: fix rcu garbage collection might_sleep() splat
Hi, rt-people
I don't think it is the correct direction.
Softirq (including local_bh_disable()) in RT kernel should be preemptible.
Fixing these problems via converting spinlock_t to raw_spinlock_t will
result that all spinlock_t used in RCU-callbacks are converted which
means almost the spinlock_t in kernel are converted.
Sudden and superficial thought.
Thanks
Lai
On 06/08/2014 04:35 PM, Mike Galbraith wrote:
>
> [ 172.743098] BUG: sleeping function called from invalid context at
> kernel/locking/rtmutex.c:768
> [ 172.743116] in_atomic(): 1, irqs_disabled(): 0, pid: 26, name: rcuos/2
> [ 172.743117] 2 locks held by rcuos/2/26:
> [ 172.743128] #0: (rcu_callback){.+.+..}, at: []
> rcu_nocb_kthread+0x1e2/0x380
> [ 172.743135] #1: (rcu_read_lock_sched){.+.+..}, at: []
> percpu_ref_kill_rcu+0xa6/0x1c0
> [ 172.743138] Preemption disabled at:[]
> rcu_nocb_kthread+0x263/0x380
> [ 172.743138]
> [ 172.743142] CPU: 0 PID: 26 Comm: rcuos/2 Not tainted 3.14.4-rt5 #31
> [ 172.743143] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG
> 12/26/2007
> [ 172.743148] 8802231aa190 8802231a5d08 81582e9e
>
> [ 172.743151] 8802231a5d28 81077aeb 880209f68140
> 880209f681c0
> [ 172.743154] 8802231a5d48 81589304 880209f68000
> 880209f68000
> [ 172.743155] Call Trace:
> [ 172.743160] [] dump_stack+0x4e/0x9c
> [ 172.743163] [] __might_sleep+0xfb/0x170
> [ 172.743167] [] rt_spin_lock+0x24/0x70
> [ 172.743171] [] free_ioctx_users+0x30/0x130
> [ 172.743174] [] percpu_ref_kill_rcu+0x1b4/0x1c0
> [ 172.743177] [] ? percpu_ref_kill_rcu+0xa6/0x1c0
> [ 172.743180] [] ? percpu_ref_kill_and_confirm+0x70/0x70
> [ 172.743183] [] rcu_nocb_kthread+0x263/0x380
> [ 172.743185] [] ? rcu_nocb_kthread+0x1e2/0x380
> [ 172.743189] [] ? rcu_report_exp_rnp.isra.52+0xc0/0xc0
> [ 172.743192] [] kthread+0xd6/0xf0
> [ 172.743194] [] ? _raw_spin_unlock_irq+0x2c/0x70
> [ 172.743197] [] ? __kthread_parkme+0x70/0x70
> [ 172.743200] [] ret_from_fork+0x7c/0xb0
> [ 172.743203] [] ? __kthread_parkme+0x70/0x70
>
> crash> gdb list *percpu_ref_kill_rcu+0x1b4
> 0x812ace34 is in percpu_ref_kill_rcu
> (include/linux/percpu-refcount.h:169).
> 164 pcpu_count = ACCESS_ONCE(ref->pcpu_count);
> 165
> 166 if (likely(REF_STATUS(pcpu_count) == PCPU_REF_PTR))
> 167 __this_cpu_dec(*pcpu_count);
> 168 else if (unlikely(atomic_dec_and_test(>count)))
> 169 ref->release(ref);
> 170
> 171 rcu_read_unlock_sched();
> 172 }
> 173
>
> Ok, so ->release() can't do anything where it may meet a sleeping lock,
> but in an -rt kernel, it does that.
>
> Convert struct kioctx ctx_lock/completion_lock to raw_spinlock_t, and
> defer final free to a time when we're not under rcu_read_lock_sched().
>
> runltp -f ltp-aio-stress.part1 runs kernel/ltp gripe free.
>
> INFO: ltp-pan reported all tests PASS
> LTP Version: 20140422
>
>###
>
> Done executing testcases.
> LTP Version: 20140422
>###
>
>
> Signed-off-by: Mike Galbraith
> ---
> fs/aio.c | 61 -
> 1 file changed, 44 insertions(+), 17 deletions(-)
>
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -125,7 +125,7 @@ struct kioctx {
> } cacheline_aligned_in_smp;
>
> struct {
> - spinlock_t ctx_lock;
> + raw_spinlock_t ctx_lock;
> struct list_head active_reqs; /* used for cancellation */
> } cacheline_aligned_in_smp;
>
> @@ -136,13 +136,16 @@ struct kioctx {
>
> struct {
> unsignedtail;
> - spinlock_t completion_lock;
> + raw_spinlock_t completion_lock;
> } cacheline_aligned_in_smp;
>
> struct page *internal_pages[AIO_RING_PAGES];
> struct file *aio_ring_file;
>
> unsignedid;
> +#ifdef CONFIG_PREEMPT_RT_BASE
> + struct rcu_head rcu;
> +#endif
> };
>
> /*-- sysctl variables*/
> @@ -334,11 +337,11 @@ static int aio_migratepage(struct addres
>* while the old page is copied to the new. This prevents new
>* events from being lost.
>*/
> - spin_lock_irqsave(>completion_lock, flags);
> + raw_spin_lock_irqsave(>completion_lock, flags);
> migrate_page_copy(new, old);
> BUG_ON(ctx->ring_pages[idx] != old);
> ctx->ring_pages[idx] = new;
> - spin_unlock_irqrestore(>completion_lock, flags);
> + raw_spin_unlock_irqrestore(>completion_lock, flags);
>
> /* The old page is no longer accessible. */
> put_page(old);
> @@ -461,14 +464,14 @@ void kiocb_set_cancel_fn(struct kiocb *r
> struct kioctx *ctx =
Re: [RFC PATCH 00/13][V3] kexec: A new system call to allow in kernel loading
On 06/06/14 at 04:04pm, Vivek Goyal wrote: > On Fri, Jun 06, 2014 at 03:37:48PM +0800, Dave Young wrote: > > On 06/05/14 at 11:01am, Vivek Goyal wrote: > > > On Thu, Jun 05, 2014 at 04:31:34PM +0800, Dave Young wrote: > > > > > > [..] > > > > > + ret = kexec_file_load(kernel_fd, info.initrd_fd, > > > > > info.command_line, > > > > > + info.command_line_len, info.kexec_flags); > > > > > > > > Vivek, > > > > > > > > I tried your patch on my uefi test machine, but kexec load fails like > > > > below: > > > > > > > > [root@localhost ~]# kexec -l /boot/vmlinuz-3.15.0-rc8+ > > > > --use-kexec2-syscall > > > > Could not find a free area of memory of 0xa000 bytes ... > > > > > > Hi Dave, > > > > > > I think this message is coming from kexec-tools from old loading path. I > > > think somehow new path did not even kick in. I tried above and I got > > > -EBADF as I did not pass initrd. Can you run gdb on kexec and see if > > > you are getting to syscall or run strace. > > > > Seems I can not reproduce the local hole fail issue but I'm sure it happens > > before the new syscall callback. > > > > This time I got -ENOEXEC. It's caused by CONFIG_EFI_MIXED=y. In case > > EFI_MIXED > > 64bit kernel runs on 32bit efi firmware thus XLF_CAN_BE_LOADED_ABOVE_4G is > > not > > set thus bzImage probe will fail with NOEXEC. > > Yep, current bzImage loader only supports loading 64bit image which can > be loaded above 4G. > > I am wondering how user space implementation is taking care of it. I guess > we are falling back to 32bit implementation where we use 32bit entry and > assume that bzImage has to be below 4G. > > We will have to do similar thing in kernel when 32bit loader comes in. > Compile that in for 64bit kernel and let it handle the case of bzImage > not being loadable above 4G. Vivek, I think current implementation is ok to only handle XLF_CAN_BE_LOADED_ABOVE_4G bzImage. Matt has sent a patch to revert the EFI_MIXED patch since 32bit loader never load kernel to above 4G space. So no worry about this issue any more. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: blk-exec.c: Cleaning up local variable address returnd
On 2014-06-06 16:37, Rickard Strandqvist wrote: Address of local variable assigned to a function parameter This was partly found using a static code analysis program called cppcheck. I'd be surprised if this was a real bug, but I agree on principle, we should not leak stack data. The code is in place since for drivers that rely on sense always being available. I will apply, thanks. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Crypto Update for 3.16
Hi Linus,
On Sun, Jun 8, 2014 at 10:56 AM, Linus Torvalds
wrote:
> On Wed, Jun 4, 2014 at 11:23 PM, Herbert Xu
> wrote:
>>
>> Here is the crypto update for 3.16:
>
> There's something odd going on with bfin_crc.h.
>
> You moved it in commit 52e6e543f2d8 ("crypto: bfin_crc - access crc
> registers by readl and writel functions").
>
> It got *deleted* by commit 3356c99ea392 ("bfin_crc: Move architecture
> independant crc header file out of the blackfin folder") which claims
> to just move things.
>
> Both of those commits are by Sonic Zhang, just came to me through two
> different trees (though your crypto tree, and through Steven Miao's
> bfin tree).
>
> I'm assuming that the delete was actually incorrect, and should have
> been a move, because it looks like the bfin_crc.c file won't compile
> without it. So I've re-instated that file.
>
> But the state of the bfin tree seems to be crap. Somebody should take
> a look at what happened here. My suspicion is that commit 3356c99ea392
> was broken by Steven Miao trying to only touch files in arch/blackfin
> or something.
Yes. I should be a move from arch/blackfin to drivers/crypto, sorry
for I only formating the arch/blackfin changes.
>
>Linus
-steven
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface
On Fri, Jun 06, 2014 at 11:21:27AM -0400, Steven Rostedt wrote: > Date: Fri, 6 Jun 2014 11:21:27 -0400 > From: Steven Rostedt > To: "Chen, Gong" > Cc: "Luck, Tony" , Borislav Petkov , > "m.che...@samsung.com" , > "linux-a...@vger.kernel.org" , LKML > > Subject: Re: [PATCH 5/7 v6] trace, RAS: Add eMCA trace event interface > X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) > > On Fri, 6 Jun 2014 02:51:41 -0400 > "Chen, Gong" wrote: > > > > +/* > > + * MCE Extended Error Log trace event > > + * > > + * These events are generated when hardware detects a corrected or > > + * uncorrected event. > > + */ > > + > > +/* memory trace event */ > > + > > +TRACE_EVENT(extlog_mem_event, > > + TP_PROTO(struct cper_sec_mem_err *mem, > > +u32 err_seq, > > +const uuid_le *fru_id, > > +const char *fru_text, > > +u8 sev), > > + > > + TP_ARGS(mem, err_seq, fru_id, fru_text, sev), > > + > > + TP_STRUCT__entry( > > + __field(u32, err_seq) > > + __field(u8, etype) > > + __field(u8, sev) > > + __field(u64, pa) > > + __field(u8, pa_mask_lsb) > > + __dynamic_array(char, fru, 48) > > + __dynamic_array(u8, data, sizeof(struct cper_mem_err_compact)) > > For constant size arrays, don't use __dynamic_array() just use > __array(). > Thanks a lot! I will update it. BTW, any comments from other guys? Boris, Tony? If not, I will send out the new version tomorrow. signature.asc Description: Digital signature
[PATCH v6] pinctrl: to avoid duplicated calling enable_pinmux_setting for a pin
From: Fan Wu
What the patch did:
1.To call pinmux_disable_setting ahead of pinmux_enable_setting in each time of
calling pinctrl_select_state
2.Remove the HW disable operation in in pinmux_disable_setting function.
3.Remove the disable ops in struct pinmux_ops
4.Remove all the disable ops users in current code base.
Notes:
1.Great thanks for the suggestion from Linus, Tony Lindgren and Stephen Warren
and Everyone that shared comments on this patch.
2.The patch also includes comment fixes from Stephen Warren.
The reason why to do this is that:
1.To avoid duplicated calling enable_setting operation without disabling
operation which will let Pin's desc->mux_usecount keep being added.
2.The HW pin disable operation is not useful for most of the vendors' platform.
And this can be used to avoid the HW glitch after using the item 1#
modification.
In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in DTS node may be like the following one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_grp_setting _grp_setting>;
pinctrl-1 = <_grp_setting _grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
}
3)When switching the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1)The switch is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without
being decreased, because the "desc" is for each physical pin while the
"setting" is for each setting node in the DTS.
Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead of enabling
"c_grp_setting" in pinctrl-1, the desc->mux_usecount will be kept added
without any chance to be decreased.
According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1)Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting repeatedly
2)"Disable"(calling pinmux_disable_setting) the "Same Pins setting", actually
two setting instance, ahead of enabling them.
Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the
setting(s) is/are existed in the new state, the Pin's mux function change
may happen when some SoC vendors defined the "pinctrl-single,function-off"
in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old
state should be marked as "disabled".
Conclusion:
1.To Remove the HW disabling operation to above the glitch mentioned above.
2.Handle the issue mentioned above by disabling all of the settings in old
state and then enable the all of the settings in new state.
Signed-off-by: Fan Wu
Acked-by: Stephen Warren
Acked-by: Patrice Chotard
Acked-by: Heiko Stuebner
Acked-by: Maxime Coquelin
---
drivers/pinctrl/core.c| 24 +++---
drivers/pinctrl/pinctrl-abx500.c | 15 -
drivers/pinctrl/pinctrl-adi2.c| 30 -
drivers/pinctrl/pinctrl-at91.c| 21
drivers/pinctrl/pinctrl-bcm2835.c | 11 ---
drivers/pinctrl/pinctrl-exynos5440.c |8 -
drivers/pinctrl/pinctrl-msm.c | 25 --
drivers/pinctrl/pinctrl-nomadik.c | 16 -
drivers/pinctrl/pinctrl-rockchip.c| 18 --
drivers/pinctrl/pinctrl-samsung.c |8 -
drivers/pinctrl/pinctrl-single.c | 56 ---
drivers/pinctrl/pinctrl-st.c |6
drivers/pinctrl/pinctrl-tb10x.c | 17 --
drivers/pinctrl/pinctrl-tegra.c | 13
drivers/pinctrl/pinctrl-tz1090-pdc.c | 28
drivers/pinctrl/pinctrl-tz1090.c | 58 -
drivers/pinctrl/pinctrl-u300.c| 14
drivers/pinctrl/pinmux.c |4 ---
drivers/pinctrl/sh-pfc/pinctrl.c | 22 -
drivers/pinctrl/sirf/pinctrl-sirf.c | 10 --
drivers/pinctrl/spear/pinctrl-spear.c |7
drivers/pinctrl/vt8500/pinctrl-wmt.c | 12 ---
include/linux/pinctrl/pinmux.h|2 --
23 files changed, 5 insertions(+), 420 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
Re: [RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?
On Sun, Jun 08, 2014 at 08:05:24PM -0400, George Spelvin wrote: > > The problem I started trying to solve is readers (entropy extractors) > monopolizing the pool lock and stalling writers (entropy mixers), which > are supposed to be fast and low overhead. Which writer are you worried about, specifically? A userspace write to /dev/random from rgnd? And have you measured this to be something significant, or is this a theoretical concern. If you've measured it, what's the conditions where this is stalling an entropy mixer a significant amount of time? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: numa: drop ZONE_ALIGN
On Sun, Jun 8, 2014 at 3:14 PM, Luiz Capitulino wrote: > In short, I believe this is just dead code for the upstream kernel but this > causes a bug for 2.6.32 based kernels. > > The setup_node_data() function is used to initialize NODE_DATA() for a node. > It gets a node id and a memory range. The start address for the memory range > is rounded up to ZONE_ALIGN and then it's used to initialize > NODE_DATA(nid)->node_start_pfn. > The 2.6.32 kernel did use the rounded up range start to register a node's > memory range with the bootmem interface by calling init_bootmem_node(). > A few steps later during bootmem initialization, the 2.6.32 kernel calls > free_bootmem_with_active_regions() to initialize the bootmem bitmap. This > function goes through all memory ranges read from the SRAT table and try > to mark them as usable for bootmem usage. However, before marking a range > as usable, mark_bootmem_node() asserts if the memory range start address > (as read from the SRAT table) is less than the value registered with > init_bootmem_node(). The assertion will trigger whenever the memory range > start address is rounded up, as it will always be greater than what is > reported in the SRAT table. This is true when the 2.6.32 kernel runs as a > HyperV guest on Windows Server 2012. Dropping ZONE_ALIGN solves the > problem there. What is e820 memmap and srat from HyperV guest? Can you post bootlog first 200 lines? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] include/linux/memblock.h: add __init to memblock_set_bottom_up
Seeing from the code, it is OK.
Reviewed-by: Tang Chen
Thanks.
On 06/07/2014 02:21 PM, Fabian Frederick wrote:
memblock_set_bottom_up is only called by
__init cmdline_parse_movable_node and __init numa_init.
Cc: Andrew Morton
Cc: Tang Chen
Signed-off-by: Fabian Frederick
---
This is untested.
include/linux/memblock.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index 8a20a51..4d6dfcf 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -198,7 +198,7 @@ phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t
align);
/*
* Set the allocation direction to bottom-up or top-down.
*/
-static inline void memblock_set_bottom_up(bool enable)
+static inline void __init memblock_set_bottom_up(bool enable)
{
memblock.bottom_up = enable;
}
@@ -213,7 +213,7 @@ static inline bool memblock_bottom_up(void)
return memblock.bottom_up;
}
#else
-static inline void memblock_set_bottom_up(bool enable) {}
+static inline void __init memblock_set_bottom_up(bool enable) {}
static inline bool memblock_bottom_up(void) { return false; }
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12.9 kern.log spam from vgaswitcheroo
On Sat, Jun 7, 2014 at 4:18 PM, Dave Airlie wrote: > cc'ing list > > On 8 June 2014 04:08, Howard Chu wrote: >> On Asus NP56D, if you use vgaswitcheroo to turn off the discrete GPU, the >> kernel starts spewing these messages endlessly, until /var/log partition >> fills up: >> >> Jun 7 17:40:27 gamba kernel: [470008.702322] [drm:radeon_cs_parser_init] >> *ERROR* VM not ac >> tive on asic! >> Jun 7 17:40:27 gamba kernel: [470008.702325] [drm:radeon_cs_ioctl] *ERROR* >> Failed to initi >> alize parser ! >> Jun 7 17:40:27 gamba kernel: [470008.702385] [drm:radeon_cs_parser_init] >> *ERROR* VM not ac >> tive on asic! >> Jun 7 17:40:27 gamba kernel: [470008.702389] [drm:radeon_cs_ioctl] *ERROR* >> Failed to initi >> alize parser ! >> >> Turning the discrete GPU back on stops the stream of messages. Something is trying to access the GPU while it's off. Make sure your version of mesa has this patch: http://cgit.freedesktop.org/mesa/mesa/commit/?id=cf0172d46ab940a691da6516057c81f28961482f Alex >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] lib/random32.c: Make prandom_u32_max efficient for powers of 2
Daniel Borkmann wrote: > On 06/08/2014 07:34 PM, Hannes Frederic Sowa wrote: >> Please check this as it makes the code more complicated and I doubt it is >> worth it. > > Agreed. Just to clarify, the goal is to be able to replace "prandom_u32() % range" all over the kernel with "prandom_u32_max(range)" and promise people that it's guaranteed to be just as good. My goal is a one-time cleanup to eliminate "prandom_u32() % range" so people will stop cutting and pasting it into new code. (FIXME: Add a kdoc update on the subject.) It uglifies the random32 code for sure, but by encapsulating the cleverness it lets all the call sites be simpler and reduces arguments about the change. E.g. have a look at all the prandom_u32 calls in net/core/pktgen.c. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] drivers/char/random.c: Is reducing locking range like this safe?
I have a few assorted cleanups in-work, but I was thinking about the
following and it's led to some thinking about the (non-)usefulness
of the out[] buffer from _mix_pool_bytes.
The problem I started trying to solve is readers (entropy extractors)
monopolizing the pool lock and stalling writers (entropy mixers), which
are supposed to be fast and low overhead.
So I thought I could rely on the "out" buffer returned from
_mix_pool_bytes to make concurrent extractors produce different output.
That led to the patch below, which drops the lock during the main pool
hash and only locks around the mix-back. (Using the mix_pool_bytes
wrapper rather than explicit locking and __mix_pool_bytes.)
But I'm not sure it's quite right.
Suppose we have a pool that's mostly all-zero, but has a small dense
high-entropy section, and no arch_get_random_long(). Narrowing the
lock lets concurrent readers get to the __mix_pool_bytes() mix-back
(last hunk of the diff) with identical SHA states.
With the original code, which fills out[] with data from just *after*
the add_ptr (i.e. the oldest portion of the pool), it's possible for
multiple readers to obtain all-zero out[] buffers and return identical
hashes.
(Or, in a less extreme case, very low-entropy out[] buffers and
strongly correlated outputs. I'll keep using "all-zero" to make
the examples simpler, and assume people can see the extrapolation.)
Well, okay, I think, easily fixed (included in the patch below):
change it to return the most recently modified section just *before*
the add_ptr, which includes the previus extractor's SHA hash. That
way, I'm guaranteed to get different data on multiple concurrent
calls and everything is okay.
But is it?
Suppose I have three concurrent callers. (I need three because the
hash folding covers up the problem with two.) The pool contains
30 bytes of entropy, so it should be possible to return uncorrelated
outputs to each of them, but as mentioned that's in a small dense
region of the pool and the area around add_ptr is all zeros.
Each hashes the pool to obtain identical 20-byte SHA-1 hashes. Then they
serialize arond calls to _mix_pool_bytes. The first gets zeros in out[],
the second gets the first's SHA-1 hash and so generates a different hash,
and the third gets the second's SHA-1 hash.
So they all produce different outputs, but the outputs (totalling 30
bytes) passed through a 20-byte choke point and so have at most 20 bytes
of entropy between them. This violates the /dev/random security goals.
Here are the solutions I've been thinking about:
1) Continue to lock the entire hashing operation.
As long as we do this, the out[] parameter to _mix_pool_bytes is
unnecessary and should be deleted. Since the pool can't change
between the bulk hash and the hash of out[], there's no point to
re-hashing some data that was just hashed. (You are sampling the
add_ptr, which differs between callers, but that's negligible.)
One way to address my concern would be to split r->lock into
r->mix_lock and r->extract_lock. Extractors would obtain the
latter for the entire hash, and only obtain the mix_lock
for the brief mix-back operation.
The downside, of course, is a second lock on the extract path, but
given that the efficiency of the extract path is not a design goal,
perhaps that's fine.
2) Shrink the lock and add a nonce (like a CPUID) to the *initial* SHA state.
This is fun because of its greater cryptographic cleverness,
but that means it should be discussed carefully first.
Due to the non-linearity of SHA hashing, this would result in
the concurrent hashes sampling different parts of the pool's
entropy, and the 20-byte entropy bottleneck would disappear.
But in this case, the out[] buffer also does not contribute to
the security guarantee and could also disappear.
Thoughts, anyone?
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 102c50d..d847367 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -499,6 +499,15 @@ static void _mix_pool_bytes(struct entropy_store *r, const
void *in,
input_rotate = ACCESS_ONCE(r->input_rotate);
i = ACCESS_ONCE(r->add_ptr);
+ /*
+* Out gets a copy of the portion of the pool most recently
+* modified by previous writers. Since add_ptr counts down,
+* this is at positive offsets from the initial value.
+*/
+ if (out)
+ for (j = 0; j < 16; j++)
+ ((__u32 *)out)[j] = r->pool[(i + j) & wordmask];
+
/* mix one byte at a time to simplify size handling and churn faster */
while (nbytes--) {
w = rol32(*bytes++, input_rotate);
@@ -527,10 +536,6 @@ static void _mix_pool_bytes(struct entropy_store *r, const
void *in,
ACCESS_ONCE(r->input_rotate) = input_rotate;
ACCESS_ONCE(r->add_ptr) = i;
smp_wmb();
-
- if (out)
- for (j = 0; j < 16; j++)
[PATCH v2] drivers/base: Fix length checks in create_syslog_header()/dev_vprintk_emit()
snprintf() returns the number of bytes that could have been written (excluding the null), not the actual number of bytes written. Given a long enough subsystem or device name, these functions will advance beyond the end of the on-stack buffer in dev_vprintk_exit(), resulting in an information leak or stack corruption. I don't know whether such a long name is currently possible. In case snprintf() returns a value >= the buffer size, do not add structured logging information. Also WARN if this happens, so we can fix the driver or increase the buffer size. Signed-off-by: Ben Hutchings --- v2: use dev_WARN() not dev_WARN_ON() drivers/base/core.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/base/core.c b/drivers/base/core.c index 20da3ad..062b7bf 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2007,6 +2007,8 @@ create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen) return 0; pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys); + if (pos >= hdrlen) + goto overflow; /* * Add device identifier DEVICE=: @@ -2038,7 +2040,14 @@ create_syslog_header(const struct device *dev, char *hdr, size_t hdrlen) "DEVICE=+%s:%s", subsys, dev_name(dev)); } + if (pos >= hdrlen) + goto overflow; + return pos; + +overflow: + dev_WARN(dev, 1, "device/subsystem name too long"); + return 0; } int dev_vprintk_emit(int level, const struct device *dev, -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Re: [PATCH] mm/mempolicy: fix sleeping function called from invalid context
On Fri, 6 Jun 2014, Gu Zheng wrote:
> >> When running with the kernel(3.15-rc7+), the follow bug occurs:
> >> [ 9969.258987] BUG: sleeping function called from invalid context at
> >> kernel/locking/mutex.c:586
> >> [ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name:
> >> python
> >> [ 9969.441175] INFO: lockdep is turned off.
> >> [ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G A
> >> 3.15.0-rc7+ #85
> >> [ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS
> >> PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012
> >> [ 9969.706052] 81a20e60 8803e941fbd0 8162f523
> >> 8803e941fd18
> >> [ 9969.795323] 8803e941fbe0 8109995a 8803e941fc58
> >> 81633e6c
> >> [ 9969.884710] 811ba5dc 880405c6b480 88041fdd90a0
> >> 2000
> >> [ 9969.974071] Call Trace:
> >> [ 9970.003403] [] dump_stack+0x4d/0x66
> >> [ 9970.065074] [] __might_sleep+0xfa/0x130
> >> [ 9970.130743] [] mutex_lock_nested+0x3c/0x4f0
> >> [ 9970.200638] [] ? kmem_cache_alloc+0x1bc/0x210
> >> [ 9970.272610] [] cpuset_mems_allowed+0x27/0x140
> >> [ 9970.344584] [] ? __mpol_dup+0x63/0x150
> >> [ 9970.409282] [] __mpol_dup+0xe5/0x150
> >> [ 9970.471897] [] ? __mpol_dup+0x63/0x150
> >> [ 9970.536585] [] ? copy_process.part.23+0x606/0x1d40
> >> [ 9970.613763] [] ? trace_hardirqs_on+0xd/0x10
> >> [ 9970.683660] [] ? monotonic_to_bootbased+0x2f/0x50
> >> [ 9970.759795] [] copy_process.part.23+0x670/0x1d40
> >> [ 9970.834885] [] do_fork+0xd8/0x380
> >> [ 9970.894375] [] ? __audit_syscall_entry+0x9c/0xf0
> >> [ 9970.969470] [] SyS_clone+0x16/0x20
> >> [ 9971.030011] [] stub_clone+0x69/0x90
> >> [ 9971.091573] [] ? system_call_fastpath+0x16/0x1b
> >>
> >> The cause is that cpuset_mems_allowed() try to take
> >> mutex_lock(_mutex)
> >> under the rcu_read_lock(which was hold in __mpol_dup()). And in
> >> cpuset_mems_allowed(),
> >> the access to cpuset is under rcu_read_lock, so in __mpol_dup, we can
> >> reduce the
> >> rcu_read_lock protection region to protect the access to cpuset only in
> >> current_cpuset_is_being_rebound(). So that we can avoid this bug.
> >>
> >> ...
> >>
> >> --- a/kernel/cpuset.c
> >> +++ b/kernel/cpuset.c
> >> @@ -1188,7 +1188,13 @@ done:
> >>
> >> int current_cpuset_is_being_rebound(void)
> >> {
> >> - return task_cs(current) == cpuset_being_rebound;
> >> + int ret;
> >> +
> >> + rcu_read_lock();
> >> + ret = task_cs(current) == cpuset_being_rebound;
> >> + rcu_read_unlock();
> >> +
> >> + return ret;
> >> }
> >
> > Looks fishy to me. If the rcu_read_lock() stabilizes
> > cpuset_being_rebound then cpuset_being_rebound can change immediately
> > after rcu_read_unlock() and `ret' is now wrong.
>
> IMO, whether cpuset_being_rebound changed or not is immaterial here, we
> just want to know whether the cpuset is being rebound at that point.
>
I think your patch addresses the problem that you're reporting but misses
the larger problem with cpuset.mems rebinding on fork(). When the
forker's task_struct is duplicated (which includes ->mems_allowed) and it
races with an update to cpuset_being_rebound in update_tasks_nodemask()
then the task's mems_allowed doesn't get updated.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: numa: drop ZONE_ALIGN
On Sun, 8 Jun 2014, Luiz Capitulino wrote: > diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h > index 4064aca..01b493e 100644 > --- a/arch/x86/include/asm/numa.h > +++ b/arch/x86/include/asm/numa.h > @@ -9,7 +9,6 @@ > #ifdef CONFIG_NUMA > > #define NR_NODE_MEMBLKS (MAX_NUMNODES*2) > -#define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT)) > > /* > * Too small node sizes may confuse the VM badly. Usually they > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > index 1d045f9..69f6362 100644 > --- a/arch/x86/mm/numa.c > +++ b/arch/x86/mm/numa.c > @@ -200,8 +200,6 @@ static void __init setup_node_data(int nid, u64 start, > u64 end) > if (end && (end - start) < NODE_MIN_SIZE) > return; > > - start = roundup(start, ZONE_ALIGN); > - > printk(KERN_INFO "Initmem setup node %d [mem %#010Lx-%#010Lx]\n", > nid, start, end - 1); > What ensures this start address is page aligned from the BIOS? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hii
Hi nice to meet you . I'm Ms Laura Roland from Switzerland, is a pleasure to contact you today,please write me back . thanks from Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
docker crashes rcuos in __blkg_release_rcu
Hi Tejun, Vivek,
I came across this crash when attempting to run the 'hello world'
example from the Getting Started section on the docker.io homepage.
Repro kernels:
(upstream linus) 3.15.0
(RHEL7 RC-2) 3.10.0-121.el7.x86_64
To reproduce, boot with slub_debug=FZPU and run the example.
% # RHEL7 needs docker-io from EPEL
% yum install
http://dl.fedoraproject.org/pub/epel/beta/7/x86_64/epel-release-7-0.1.noarch.rpm
% rpm -ivh epel-release-7-0.1.noarch.rpm
% yum install docker-io
% systemctl start docker
% docker run ubuntu /bin/echo hello world
The host crashes every time with the following stack trace:
general protection fault: [#1] SMP
Modules linked in: veth xt_addrtype xt_conntrack iptable_filter ipt_MASQUERADE
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
ip_tables bridge stp llc dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio
libcrc32c loop bonding sg x86_pkg_temp_thermal coretemp crct10dif_pclmul
crc32_pclmul crc32c_intel igb ixgbe ghash_clmulni_intel aesni_intel nfsd lrw
gf128mul glue_helper ablk_helper dm_service_time cryptd pcspkr ptp auth_rpcgss
ntb pps_core nfs_acl ses lockd mdio i2c_algo_bit enclosure ipmi_devintf dca
ipmi_msghandler i2c_core dm_multipath sunrpc dm_mod ext4 mbcache jbd2 raid1
sd_mod crc_t10dif crct10dif_common sr_mod cdrom qla2xxx mpt3sas mpt2sas
scsi_transport_fc usb_storage scsi_tgt raid_class scsi_transport_sas
CPU: 21 PID: 30 Comm: rcuos/21 Not tainted 3.15.0 #1
Hardware name: Stratus ftServer 6400/G7LAZ, BIOS BIOS Version 6.3:57 12/25/2013
task: 880854021de0 ti: 88085403c000 task.ti: 88085403c000
RIP: 0010:[] []
_raw_spin_lock_irq+0x15/0x60
RSP: 0018:88085403fdf0 EFLAGS: 00010086
RAX: 0002 RBX: 0010 RCX:
RDX: 60ef80008248 RSI: 0286 RDI: 6b6b6b6b6b6b6b6b
RBP: 88085403fdf0 R08: 0286 R09: 9f39
R10: 00020001 R11: 00020001 R12: 88103c17a130
R13: 88103c17a080 R14: R15:
FS: () GS:88107fca() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006e5ab8 CR3: 0193d000 CR4: 000407e0
Stack:
88085403fe18 812cbfc2 88103c17a130
88103c17a130 88085403fec0 810d1d28 880854021de0
880854021de0 88107fcaec58 88085403fe80 88107fcaec30
Call Trace:
[] __blkg_release_rcu+0x72/0x150
[] rcu_nocb_kthread+0x1e8/0x300
[] ? abort_exclusive_wait+0xb0/0xb0
[] ? rcu_start_gp+0x40/0x40
[] kthread+0xe1/0x100
[] ? kthread_create_on_node+0x1a0/0x1a0
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x1a0/0x1a0
Code: ff 47 04 48 8b 7d 08 be 00 02 00 00 e8 55 48 a4 ff 5d c3 0f 1f 00 66 66
66 66 90 55 48 89 e5 fa 66 66 90 66 66 90 b8 00 00 02 00 0f c1 07 89 c2 c1
ea 10 66 39 c2 75 02 5d c3 83 e2 fe 0f b7
RIP [] _raw_spin_lock_irq+0x15/0x60
RSP
crash> dis -l _raw_spin_lock_irq
kernel/locking/spinlock.c: 166
<_raw_spin_lock_irq>:data32 data32 data32 xchg %ax,%ax
<_raw_spin_lock_irq+0x5>:push %rbp
<_raw_spin_lock_irq+0x6>:mov%rsp,%rbp
arch/x86/include/asm/paravirt.h: 814
<_raw_spin_lock_irq+0x9>:cli
<_raw_spin_lock_irq+0xa>:data32 xchg %ax,%ax
<_raw_spin_lock_irq+0xd>:data32 xchg %ax,%ax
arch/x86/include/asm/spinlock.h: 86
<_raw_spin_lock_irq+0x10>: mov$0x2,%eax
<_raw_spin_lock_irq+0x15>: lock xadd %eax,(%rdi) <<
arch/x86/include/asm/spinlock.h:
82 static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
83 {
84 register struct __raw_tickets inc = { .tail = TICKET_LOCK_INC };
85
86 inc = xadd(>tickets, inc); <<
.tickets is offset 0 from arch_spinlock_t, so RDI should be the
arch_spinlock_t lock:
RDI: 6b6b6b6b6b6b6b6b
Back up a frame and get bearings...
crash> dis -l __blkg_release_rcu
block/blk-cgroup.c: 402
<__blkg_release_rcu+0x56>: cmpq $0x0,-0x80(%r12)
<__blkg_release_rcu+0x5c>: je 0x812cc001
<__blkg_release_rcu+0xb1>
block/blk-cgroup.c: 403
<__blkg_release_rcu+0x5e>: mov-0xb0(%r12),%rax
include/linux/spinlock.h: 328
<__blkg_release_rcu+0x66>: mov0x460(%rax),%rdi
<__blkg_release_rcu+0x6d>: callq 0x8162e9d0 <_raw_spin_lock_irq>
block/blk-cgroup.c:
387 void __blkg_release_rcu(struct rcu_head *rcu_head)
388 {
...
400 /* release the blkcg and parent blkg refs this blkg has been
holding */
401 css_put(>blkcg->css);
402 if (blkg->parent) {
403 spin_lock_irq(blkg->q->queue_lock);
404 blkg_put(blkg->parent);
405 spin_unlock_irq(blkg->q->queue_lock);
406 }
RAX is the struct request_queue*, but has been re-used by
_raw_spin_lock_irq. How about R12?
crash> struct -o blkcg_gq | grep b0
[PATCH] x86: numa: drop ZONE_ALIGN
In short, I believe this is just dead code for the upstream kernel but this causes a bug for 2.6.32 based kernels. The setup_node_data() function is used to initialize NODE_DATA() for a node. It gets a node id and a memory range. The start address for the memory range is rounded up to ZONE_ALIGN and then it's used to initialize NODE_DATA(nid)->node_start_pfn. However, a few function calls later free_area_init_node() is called and it overwrites NODE_DATA()->node_start_pfn with the lowest PFN for the node. Here's the call callchain: setup_arch() initmem_init() x86_numa_init() numa_init() numa_register_memblks() setup_node_data()<-- initializes NODE_DATA()->node_start_pfn ... x86_init.paging.pagetable_init() paging_init() zone_sizes_init() free_area_init_nodes() free_area_init_node()<-- overwrites NODE_DATA()->node_start_pfn This doesn't seem to cause any problems to the current kernel because the rounded up start address is not really used. However, I came accross this dead assignment while debugging a real issue on a 2.6.32 based kernel. The 2.6.32 kernel did use the rounded up range start to register a node's memory range with the bootmem interface by calling init_bootmem_node(). A few steps later during bootmem initialization, the 2.6.32 kernel calls free_bootmem_with_active_regions() to initialize the bootmem bitmap. This function goes through all memory ranges read from the SRAT table and try to mark them as usable for bootmem usage. However, before marking a range as usable, mark_bootmem_node() asserts if the memory range start address (as read from the SRAT table) is less than the value registered with init_bootmem_node(). The assertion will trigger whenever the memory range start address is rounded up, as it will always be greater than what is reported in the SRAT table. This is true when the 2.6.32 kernel runs as a HyperV guest on Windows Server 2012. Dropping ZONE_ALIGN solves the problem there. Signed-off-by: Luiz Capitulino --- arch/x86/include/asm/numa.h | 1 - arch/x86/mm/numa.c | 2 -- 2 files changed, 3 deletions(-) diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h index 4064aca..01b493e 100644 --- a/arch/x86/include/asm/numa.h +++ b/arch/x86/include/asm/numa.h @@ -9,7 +9,6 @@ #ifdef CONFIG_NUMA #define NR_NODE_MEMBLKS(MAX_NUMNODES*2) -#define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT)) /* * Too small node sizes may confuse the VM badly. Usually they diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c index 1d045f9..69f6362 100644 --- a/arch/x86/mm/numa.c +++ b/arch/x86/mm/numa.c @@ -200,8 +200,6 @@ static void __init setup_node_data(int nid, u64 start, u64 end) if (end && (end - start) < NODE_MIN_SIZE) return; - start = roundup(start, ZONE_ALIGN); - printk(KERN_INFO "Initmem setup node %d [mem %#010Lx-%#010Lx]\n", nid, start, end - 1); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: bcm: nvm.c: Cleaning up a array that is filled incompletely
Hi I think someone missed the count sizeof type in memcpy. I'm no expert on this code. But I wonder if also the the next for loop wrong? It will fill with 0XFF00 but it is not a complete 0X you're looking for? So something like: memset([sigOffset], 0xFF, MAX_RW_SIZE * sizeof(PCHAR)); Rickard Strandqvist (1): MY_FIL_NAMN Cleaning up a array that is filled incompletely drivers/staging/bcm/nvm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: bcm: nvm.c: Cleaning up a array that is filled incompletely
Array 'SigBuff' is filled incompletely.
Someone forget to multiply for the sizeof type.
This was partly found using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/staging/bcm/nvm.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/bcm/nvm.c b/drivers/staging/bcm/nvm.c
index 63be3be..d56ca3b 100644
--- a/drivers/staging/bcm/nvm.c
+++ b/drivers/staging/bcm/nvm.c
@@ -3591,7 +3591,7 @@ int BcmCopyISO(struct bcm_mini_adapter *Adapter, struct
bcm_flash2x_copy_section
if (IsThisHeaderSector == TRUE) {
/* If this is header sector write 0x at
the sig time and in last write sig */
- memcpy(SigBuff, Buff + sigOffset, MAX_RW_SIZE);
+ memcpy(SigBuff, Buff + sigOffset,
sizeof(SigBuff));
for (i = 0; i < MAX_RW_SIZE; i++)
*(Buff + sigOffset + i) = 0xFF;
@@ -3704,7 +3704,7 @@ int BcmCopyISO(struct bcm_mini_adapter *Adapter, struct
bcm_flash2x_copy_section
if (IsThisHeaderSector == TRUE) {
/* If this is header sector write 0x at
the sig time and in last write sig */
- memcpy(SigBuff, Buff + sigOffset, MAX_RW_SIZE);
+ memcpy(SigBuff, Buff + sigOffset,
sizeof(SigBuff));
for (i = 0; i < MAX_RW_SIZE; i++)
*(Buff + sigOffset + i) = 0xFF;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interactivity regression since v3.11 in mm/vmscan.c
On Sat, Jun 7, 2014 at 11:24 AM, Linus Torvalds wrote: > > Comments? Mel, this code is mostly attributed to you, I'd like to hear > what you think in particular. In the meantime, I've removed the "nr_unqueued_dirty == nr_taken" check for congestion_wait(), since I can't see how it can possibly be sensible, and Felipe confirmed that it fixes his interactivity issue. Nobody commented on it, but let's see if we get reactions to the behavior changing.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Mismatch in gmch_pfit.lvds_border_bits on EeePC 900
With a tree that is close to 3.15 final I'm regularly seeing the following on my EeePC 900 when starting ioquake3: [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0) [ cut here ] WARNING: CPU: 0 PID: 1594 at drivers/gpu/drm/i915/intel_display.c:9834 check_crtc_state+0x998/0x9ef() pipe state doesn't match! CPU: 0 PID: 1594 Comm: Xorg Not tainted 3.15.0-rc8-00106-ge585b54 #49 Hardware name: ASUSTeK Computer INC. 900/900, BIOS 100603/03/2009 b0485438 b011f61f b057c98a ebb03b04 063a b057b5f4 266a b02c31ef b02c31ef ee42c000 ee488c00 ee488d74 b011f684 0009 ebb03aec b057c98a ebb03b04 b02c31ef b057b5f4 266a b057c98a ebb03bdc Call Trace: [] ? dump_stack+0xa/0x13 [] ? warn_slowpath_common+0x70/0x85 [] ? check_crtc_state+0x998/0x9ef [] ? check_crtc_state+0x998/0x9ef [] ? warn_slowpath_fmt+0x33/0x37 [] ? check_crtc_state+0x998/0x9ef [] ? intel_modeset_check_state+0x353/0x5fb [] ? intel_set_mode+0x2a/0x32 [] ? intel_crtc_set_config+0x8c9/0x962 [] ? idr_alloc+0xb5/0xc3 [] ? drm_mode_set_config_internal+0x39/0x9b [] ? drm_mode_setcrtc+0x397/0x438 [] ? drm_crtc_check_viewport+0xef/0xef [] ? drm_ioctl+0x327/0x38f [] ? drm_crtc_check_viewport+0xef/0xef [] ? do_sync_read+0x5a/0x7f [] ? drm_version+0x73/0x73 [] ? do_vfs_ioctl+0x350/0x419 [] ? recalc_sigpending+0xe/0x36 [] ? __set_task_blocked+0x61/0x67 [] ? __set_current_blocked+0xd/0xf [] ? sigprocmask+0x77/0x87 [] ? SyS_ioctl+0x31/0x54 [] ? sysenter_do_call+0x12/0x26 [] ? klist_release+0x14/0x87 ---[ end trace 900fd39ab2e2b03f ]--- -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless-next 2014-06-06
From: "John W. Linville" Date: Fri, 6 Jun 2014 12:05:58 -0400 > Please accept this batch of fixes intended for the 3.16 stream. Pulled, thanks John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] hwmon: (ina2xx) Cast to s16 on shunt and current regs
All devices supported by ina2xx are bidirectional and reports the
measured shunt voltage and power values as a signed 16 bit, but the
current driver implementation caches all registers as u16, leading to an
incorrect sign extension when reporting to the userspace in
ina2xx_get_value().
This patch fixes the problem by casting the signed registers to s16.
Tested on an INA219.
Signed-off-by: Fabio Baltieri
---
drivers/hwmon/ina2xx.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 93d26e8..bfd3f3e 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -148,7 +148,8 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
switch (reg) {
case INA2XX_SHUNT_VOLTAGE:
- val = DIV_ROUND_CLOSEST(data->regs[reg],
+ /* signed register */
+ val = DIV_ROUND_CLOSEST((s16)data->regs[reg],
data->config->shunt_div);
break;
case INA2XX_BUS_VOLTAGE:
@@ -160,8 +161,8 @@ static int ina2xx_get_value(struct ina2xx_data *data, u8
reg)
val = data->regs[reg] * data->config->power_lsb;
break;
case INA2XX_CURRENT:
- /* LSB=1mA (selected). Is in mA */
- val = data->regs[reg];
+ /* signed register, LSB=1mA (selected), in mA */
+ val = (s16)data->regs[reg];
break;
default:
/* programmer goofed */
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8723be: hw.c: Cleaning up if statement that always evaluates to false
(Please do not top-post.) On Sunday 08 June 2014 22:47:31 Rickard Strandqvist wrote: > I found this error in some of the files. And after discussion with > Larry Finger and Peter Wu, it was decided that all files with this if > statement should change. > > But of course I should update the comment to something more suitable. Right, do not forget to use [PATCH v2] as prefix and adjust the subject too as this is no longer just "cleaning up a statement that always evaluates to false", but rather "fix [insert stuff here] mask" (for the 0xfc cases). The commit message must describe why the change is beneficial, see other commit messages for examples. Kind regards, Peter > 2014-06-08 22:35 GMT+02:00 David Rientjes : > > On Sun, 8 Jun 2014, Rickard Strandqvist wrote: > > > >> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always > >> false > >> > > > > Where is the 0xfc that your converting? > > > >> After pointing this out, Larry Finger informed what would be the correct > >> one. > >> '(X & 0x3) == 0x3' > >> > > > > This is already what it is, just say that you're replacing it with the > > constant. > > > >> Signed-off-by: Rickard Strandqvist > >> --- > >> drivers/net/wireless/rtlwifi/rtl8723be/hw.c |2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > >> b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > >> index 0fdf090..b61044f 100644 > >> --- a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > >> +++ b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > >> @@ -1197,7 +1197,7 @@ static int _rtl8723be_set_media_status(struct > >> ieee80211_hw *hw, > >> } > >> rtl_write_byte(rtlpriv, (MSR), bt_msr); > >> rtlpriv->cfg->ops->led_control(hw, ledaction); > >> - if ((bt_msr & 0x03) == MSR_AP) > >> + if ((bt_msr & MSR_AP) == MSR_AP) > >> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); > >> else > >> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] numa,sched: fix load_to_imbalanced logic inversion
This function is supposed to return true if the new load imbalance is worse than the old one. It didn't. I can only hope brown paper bags are in style. Now things converge much better on both the 4 node and 8 node systems. I am not sure why this did not seem to impact specjbb performance on the 4 node system, which is the system I have full-time access to. This bug was introduced recently, with commit e63da036 Signed-off-by: Rik van Riel --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6a90f67..7fb3e47 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1112,7 +1112,7 @@ static bool load_too_imbalanced(long orig_src_load, long orig_dst_load, old_imb = orig_dst_load * 100 - orig_src_load * env->imbalance_pct; /* Would this change make things worse? */ - return (old_imb > imb); + return (imb > old_imb); } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] hwmon: (ina2xx) Change register cache to signed
On Sun, Jun 8, 2014 at 9:30 PM, Guenter Roeck wrote: > On Sun, Jun 08, 2014 at 01:16:00PM -0700, Guenter Roeck wrote: >> On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote: >> > All devices supported by the ina2xx driver are bidirectional and reports >> > the measured value as a signed 16 bit, but the current driver >> > implementation caches the number as an u16, leading to an incorrect sign >> > extension when reporting to the userspace in ina2xx_get_value(). >> > >> > This patch fixes the problem by using a s16 instead, and has been tested >> > on an INA219. >> > >> > Signed-off-by: Fabio Baltieri >> >> Applied. >> > Actually, no, this won't work. The statement above is only correct for current > and shunt voltage measurements, but not for power measurements and not for bus > voltage measurements. Changing the register to s16 won't help; conversion > needs > to be done in ina2xx_get_value() for shunt voltage and current measurement > only. > Otherwise we just move the bug from current/shunt voltage measurements to > power / bus voltage measurements. > > Even more interesting, the power is supposed to be the product of Bus voltage > and current, and the latter can be negative. However, the power register > description does not suggest that the upper bit would be a sign bit. So there > is some discrepancy in the datasheet, and we'll need some real-world data to > understand if the upper power bit is signed or not. Hi Guenter, looks like you're right here, I wasn't paying too attention to the power register and it actually always reads positive, even when the current is flowing in the reverse direction, real data from the ina219: [55694.263502] shunt_voltage=fb46 [55694.263691] bus_voltage=20c2 [55694.263847] power=00fe [55694.263954] current=fb46 I'll send a v2 to only cast the two signed register then. Many thanks for spotting this! Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] lib/random32.c: Make prandom_u32_max efficient for powers of 2
Thank you for your comments!
> Have you checked assembler output if this helps anything at all? Constant
> propagation in the compiler should be able to figure that out all by
> itself. The only places I use __builtin_constant_p today are where I
> also make use of inline assembler.
Yes, I did. (I'll expand the commit comment for v2; my bad.)
It seems that GCC isn't smart enough to reduce this to a single shift.
With the multiply and reduce, the code looks like:
callprandom_u32
xorl%edx, %edx
shldl $4, %eax, %edx
movl%edx, %eax
Instead of the hoped-for
callprandom_u32
shrl$28, %eax
Converting to a single mask is something the compiler can't do,
because it doesn't understand that using the lsbits instead of the
msbits is okay.
With the mask, it turns into the spectacularly simple:
callprandom_u32
andl$15, %eax
An interesting question is which is preferred in general.
The AND allows non-constant powers of 2 without requiring CLZ. But I
don't recall seeing that actually happen anywhere. And the shift allows
a smaller encoding (8-bit rather than 32-bit immediate constant) when
the power of 2 is known at compile time and is larger than 128 (for
example, PAGE_SIZE).
Me, I thought it was in the noise and not worth stressing about,
but I also understand the hackers's urge for maximum tweaking.
The other thing that I couldn't think of a clean wrapper for is the
"probability 1 in N" case that happens in several bits of code.
For example, in drivers/mtd/ubi/debug.h, I made the following change:
static inline int ubi_dbg_is_bitflip(const struct ubi_device *ubi)
{
- if (ubi->dbg.emulate_bitflips)
- return !(prandom_u32() % 200);
- return 0;
+ return ubi->dbg.emulate_bitflips && prandom_u32() < -1u/200;
}
GCC doesn't know how to optimize "prandom_u32_max(200) == 0", which
is basically the same. It spits out:
callprandom_u32
movl%eax, %edx
movl$200, %eax
mull%edx
testl %edx, %edx
I couldn't think of a good enough function name for this, so I just left
it as inline code. (Using "-1u/200" rather than the technically correct
"(u32)(((u64)1 << 32)/200)" is okay as long as 200 isn't a power of 2, and
even if it were, the error wouldn't matter since it's approximate anyway.)
> Btw, IIRC there is a function is_power_of_2 somewhere. ;)
In ; thanks for the pointer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8723be: hw.c: Cleaning up if statement that always evaluates to false
Hi Quite right! I found this error in some of the files. And after discussion with Larry Finger and Peter Wu, it was decided that all files with this if statement should change. But of course I should update the comment to something more suitable. Kind regards Rickard Strandqvist 2014-06-08 22:35 GMT+02:00 David Rientjes : > On Sun, 8 Jun 2014, Rickard Strandqvist wrote: > >> I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false >> > > Where is the 0xfc that your converting? > >> After pointing this out, Larry Finger informed what would be the correct one. >> '(X & 0x3) == 0x3' >> > > This is already what it is, just say that you're replacing it with the > constant. > >> Signed-off-by: Rickard Strandqvist >> --- >> drivers/net/wireless/rtlwifi/rtl8723be/hw.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c >> b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c >> index 0fdf090..b61044f 100644 >> --- a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c >> +++ b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c >> @@ -1197,7 +1197,7 @@ static int _rtl8723be_set_media_status(struct >> ieee80211_hw *hw, >> } >> rtl_write_byte(rtlpriv, (MSR), bt_msr); >> rtlpriv->cfg->ops->led_control(hw, ledaction); >> - if ((bt_msr & 0x03) == MSR_AP) >> + if ((bt_msr & MSR_AP) == MSR_AP) >> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); >> else >> rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8821ae: rtl8821ae: hw.c: Cleaning up if statement that always evaluates to false
On Sun, 8 Jun 2014, Rickard Strandqvist wrote: > I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false > The test you're changing is '(X & ~0xfc) == 0x3' which is not always false, so is (bt_msr & MSR_AP) == MSR_AP or (bt_msr & ~MSR_AP) == MSR_AP correct? Either way, your changelog makes no sense in combination with your patch. > After pointing this out, Larry Finger informed what would be the correct one. > '(X & 0x3) == 0x3' > > Signed-off-by: Rickard Strandqvist > --- > drivers/staging/rtl8821ae/rtl8821ae/hw.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8821ae/rtl8821ae/hw.c > b/drivers/staging/rtl8821ae/rtl8821ae/hw.c > index 1b8583b..52322e3 100644 > --- a/drivers/staging/rtl8821ae/rtl8821ae/hw.c > +++ b/drivers/staging/rtl8821ae/rtl8821ae/hw.c > @@ -1623,7 +1623,7 @@ static int _rtl8821ae_set_media_status(struct > ieee80211_hw *hw, > > rtl_write_byte(rtlpriv, (MSR), bt_msr); > rtlpriv->cfg->ops->led_control(hw, ledaction); > - if ((bt_msr & ~0xfc) == MSR_AP) > + if ((bt_msr & MSR_AP) == MSR_AP) > rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); > else > rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8723be: hw.c: Cleaning up if statement that always evaluates to false
On Sun, 8 Jun 2014, Rickard Strandqvist wrote: > I find a logical error in an if statement '(X & 0xfc) == 0x3' is always false > Where is the 0xfc that your converting? > After pointing this out, Larry Finger informed what would be the correct one. > '(X & 0x3) == 0x3' > This is already what it is, just say that you're replacing it with the constant. > Signed-off-by: Rickard Strandqvist > --- > drivers/net/wireless/rtlwifi/rtl8723be/hw.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > index 0fdf090..b61044f 100644 > --- a/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > +++ b/drivers/net/wireless/rtlwifi/rtl8723be/hw.c > @@ -1197,7 +1197,7 @@ static int _rtl8723be_set_media_status(struct > ieee80211_hw *hw, > } > rtl_write_byte(rtlpriv, (MSR), bt_msr); > rtlpriv->cfg->ops->led_control(hw, ledaction); > - if ((bt_msr & 0x03) == MSR_AP) > + if ((bt_msr & MSR_AP) == MSR_AP) > rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x00); > else > rtl_write_byte(rtlpriv, REG_BCNTCFG + 1, 0x66); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lm-sensors] [PATCH] hwmon: (ina2xx) Change register cache to signed
On Sun, Jun 08, 2014 at 01:16:00PM -0700, Guenter Roeck wrote: > On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote: > > All devices supported by the ina2xx driver are bidirectional and reports > > the measured value as a signed 16 bit, but the current driver > > implementation caches the number as an u16, leading to an incorrect sign > > extension when reporting to the userspace in ina2xx_get_value(). > > > > This patch fixes the problem by using a s16 instead, and has been tested > > on an INA219. > > > > Signed-off-by: Fabio Baltieri > > Applied. > Actually, no, this won't work. The statement above is only correct for current and shunt voltage measurements, but not for power measurements and not for bus voltage measurements. Changing the register to s16 won't help; conversion needs to be done in ina2xx_get_value() for shunt voltage and current measurement only. Otherwise we just move the bug from current/shunt voltage measurements to power / bus voltage measurements. Even more interesting, the power is supposed to be the product of Bus voltage and current, and the latter can be negative. However, the power register description does not suggest that the upper bit would be a sign bit. So there is some discrepancy in the datasheet, and we'll need some real-world data to understand if the upper power bit is signed or not. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] lib/random32.c: Use instead of hand-rolling it
On Sun, Jun 8, 2014, at 5:40, George Spelvin wrote: > > Seems fine by me, since it's random anyway archs might not care > > about the *_le32, though this might yield additional work in some > > cases I presume. > > If you think that's okay, sure. I kept it consistent to get byte-for-byte > identical results. > > If variations in that are allowed, that can also > simplify the trailing storage case: > > + if (bytes & 2) > + put_unaligned_le16((u16)random, p+i); > + if (bytes & 1) > + p[i+bytes-1] = (u8)(random >> 16); Yes, please! Otherwise the code looks much too complicated for what it does. > > Nit: '(u8) random' > > Actually, my style and most of the kerel is to not put > a space in a cast, since it binds so tighty. > > E.g. compare > > git grep ')[a-z]' kernel/ > git grep ') [a-z]' kernel/ > > Notice that the second is alsmost all comments. > (There are some spaces in kernel/ptrace.v.) > > I'd rather leave it without the space unless you feel > very strongly about it. IMHO I wouldn't put a whitespace here. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hwmon: (ina2xx) Change register cache to signed
On Sat, Jun 07, 2014 at 09:47:01PM +0100, Fabio Baltieri wrote: > All devices supported by the ina2xx driver are bidirectional and reports > the measured value as a signed 16 bit, but the current driver > implementation caches the number as an u16, leading to an incorrect sign > extension when reporting to the userspace in ina2xx_get_value(). > > This patch fixes the problem by using a s16 instead, and has been tested > on an INA219. > > Signed-off-by: Fabio Baltieri Applied. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] lib/random32.c: Make prandom_u32_max efficient for powers of 2
On 06/08/2014 07:34 PM, Hannes Frederic Sowa wrote: ... Please check this as it makes the code more complicated and I doubt it is worth it. Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] lib/random32.c: Randomize timeout to the millisecond, not the second
On 06/08/2014 02:42 PM, George Spelvin wrote: Note, when you talk about efficiency here, this is called once every 40+ secs ... ;) Agreed, in this case the code size saving (avoid a function call) is the main benefit. And I prefer to avoid inefficiency on general priinciples, if it's not serving some other goal. Hm, don't think it will make much of a difference. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.14.6 1/1] pinctrl/sh-pfc: fix pfc-r8a7790 pin mux data for IPSR5 bug
From: Sathish Kumar Balasubramaniam This patch fixes a bug in the list of peripheral functions for the IPSR5 pin mux configuration of the PFC (Pin Function Controller) of the Renesas R-Car H2 SoC (R8A7790). There should be exactly 8 values listed for the IP5_23_21 peripheral function which is using 3 bits. But there are 9 values present in the list. This bug unexpectedly increases the internal position variable by 1 which is used by the PFC framework to identify the peripheral function. Due to this bug, peripheral function configuration from IP5_20_18 to IP5_2_0 may not work properly. This issue can be easily reproduced by setting the FN_I2C1_SDA ( IP5_9_6 [4] ) which has the function value of 9 but the actual function value is set as 10 due to this bug. --- --- linux-3.14.6/drivers/pinctrl/sh-pfc/pfc-r8a7790.c.original2014-06-08 22:03:44.681669692 +0530 +++ linux-3.14.6/drivers/pinctrl/sh-pfc/pfc-r8a7790.c2014-06-08 22:02:10.361673511 +0530 @@ -4624,7 +4624,7 @@ static const struct pinmux_cfg_reg pinmu /* IP5_23_21 [3] */ FN_WE1_N, FN_IERX, FN_CAN1_RX, FN_VI1_G4, FN_VI1_G4_B, FN_VI2_R6, FN_SCIFA0_CTS_N_B, -FN_IERX_C, 0, +FN_IERX_C, /* IP5_20_18 [3] */ FN_WE0_N, FN_IECLK, FN_CAN_CLK, FN_VI2_VSYNC_N, FN_SCIFA0_TXD_B, FN_VI2_VSYNC_N_B, 0, 0, Signed-off-by: Sathish Kumar Balasubramaniam ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/vdso changes for v3.16
> On Jun 8, 2014, at 10:18, Sam Ravnborg wrote: > > I would say that tools/include/tools/* should be considered the baseline > for programs running on the host. > So therefore unconditionally adding -I$(srctree)/tools/include should then > be OK. > >Sam I think we should do this, but I didn't yet because linux/types.h in that directory shadows uapi/linux/types.h which probably should be fixed first. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.15 .. and continuation of merge window
So I ended up doing an rc8 because I was a bit worried about some
last-minute dcache fixes, but it turns out that nobody seemed to even
notice those. We did have other issues during the week, though, so it
was just as well. The futex fixes and cleanups may stand out, but as
usual there's various other random fixes since rc8 in there too:
mainly drivers (drm, networking, sound, usb etc), networking,
scheduling and perf tooling.
But it's all been fairly small and quiet, which *may* of course be due
to the fact that last week was also the first week of the merge window
for 3.16. That might have distracted some developers. I'm not entirely
convinced I liked the overlap, but it seemed to work ok, and unless
people scream really loudly ("Please don't _ever_ do that again") and
give good reasons for doing so, I might end up doing that overlapping
merge window in the future too if it ends up helping out with some
particular timing issue.
That said, I also don't think it was such a wonderful experience that
I'd want to necessarily do the overlap every time, without a good
specific reason for doing so. It was kind of nice being productive
during the last week or rc (which is usually quite boring and dead),
but I think it might be a distraction when people should be worrying
about the stability of the rc.
Of course, maybe the overlap ends up meaning that we get less noise
during the last week of stabilization, and it actually helps. It could
go either way. I'd be interested to hear what people thought, although
I _suspect_ most people don't feel strongly either way.
Anyway, with 3.15 released, my "master" branch has already merged the
work in my "next" branch on my local machine, and I'll be
decommissioning the "next" branch once I push that all out. After
that, any future merge window work will happen on "master", and we'll
be back to the normal single-branch model for my tree.
Linus
---
Alan Stern (1):
USB: Avoid runtime suspend loops for HCDs that can't handle suspend/resume
Aleksander Morgado (3):
net: qmi_wwan: add Netgear AirCard 341U
net: qmi_wwan: add additional Sierra Wireless QMI devices
net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI
Alex Deucher (1):
drm/radeon/dpm: resume fixes for some systems
Alexej Starschenko (1):
USB: serial: option: add support for Novatel E371 PCIe card
Andrey Ryabinin (1):
mm: rmap: fix use-after-free in __put_anon_vma
Andy Lutomirski (1):
x86, vdso: Fix an OOPS accessing the HPET mapping w/o an HPET
Bart De Schuymer (1):
ebtables: Update MAINTAINERS entry.
Ben Hutchings (2):
Staging: speakup: Move pasting into a work item
Staging: speakup: Update __speakup_paste_selection() tty
(ab)usage to match vt
Bjørn Mork (1):
usb: cdc-wdm: export cdc-wdm uapi header
Christian König (3):
drm/radeon: fix vm buffer size estimation
drm/radeon: sync page table updates
drm/radeon: use the CP DMA on CIK
Dan Carpenter (1):
qlcnic: info leak in qlcnic_dcb_peer_app_info()
Dave Young (2):
x86/efi: earlyprintk=efi,keep fix
x86/efi: Do not export efi runtime map in case old map
Dirk Brandewie (3):
intel_pstate: Remove C0 tracking
intel_pstate: Correct rounding in busy calculation
intel_pstate: add sample time scaling
Doug Smythies (1):
intel_pstate: Improve initial busy calculation
Emmanuel Grumbach (1):
iwlwifi: mvm: disable beacon filtering
Eric Dumazet (1):
net: fix inet_getid() and ipv6_select_ident() bugs
Eric W. Biederman (1):
netlink: Only check file credentials for implicit destinations
Filipe Manana (1):
Btrfs: send, fix corrupted path strings for long paths
George McCollister (1):
USB: ftdi_sio: add NovaTech OrionLXm product ID
Greg Kroah-Hartman (1):
USB: cdc-wdm: properly include types.h
Ian Abbott (1):
staging: comedi: ni_daq_700: add mux settling delay
Igor Mammedov (3):
x86: Fix list/memory corruption on CPU hotplug
x86/smpboot: Log error on secondary CPU wakeup failure at ERR level
x86/smpboot: Initialize secondary CPU only if master CPU will wait for it
Ivan Mikhaylov (2):
emac: add missing support of 10mbit in emac/rgmii
emac: aggregation of v1-2 PLB errors for IER register
Jack Morgenstein (1):
net/mlx4_core: Reset RoCE VF gids when guest driver goes down
Jean Delvare (1):
net: ec_bhf: Add runtime dependencies
Jianyu Zhan (1):
kernfs: move the last knowledge of sysfs out from kernfs
Jiri Pirko (1):
team: fix mtu setting
Johan Hovold (1):
USB: io_ti: fix firmware download on big-endian machines (part 2)
Jon Maxwell (1):
bridge: notify user space after fdb update
Kirill Tkhai (1):
sched/dl: Fix race in dl_task_timer()
Kristian Evensen (1):
ipheth: Add support for iPad 2 and iPad 3
Leon Yu (1):
net: filter: fix possible memory leak in __sk_prepare_filter()
[PATCH v9 3/5] ARM: sunxi: Add pins for IR controller on A20 to dtsi
This patch adds pins for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 0ae2b77..c057c3e 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -724,6 +724,20 @@
allwinner,drive = <2>;
allwinner,pull = <0>;
};
+
+ ir0_pins_a: ir0@0 {
+ allwinner,pins = "PB3","PB4";
+ allwinner,function = "ir0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ ir1_pins_a: ir1@0 {
+ allwinner,pins = "PB22","PB23";
+ allwinner,function = "ir1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 5/5] ARM: sunxi: Enable IR controller on cubieboard 2 and cubietruck in dts
This patch enables two IR devices in dts:
- One IR device physically found on Cubieboard 2
- One IR device physically found on Cubietruck
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index feeff64..b44d61b 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -65,6 +65,12 @@
};
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index e288562..5f5c31d 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -121,6 +121,12 @@
};
};
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+ };
+
uart0: serial@01c28000 {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 4/5] ARM: sunxi: Add IR controllers on A20 to dtsi
This patch adds records for two IR controllers on A20
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index c057c3e..fe1f8ff 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -763,6 +763,24 @@
interrupts = <0 24 4>;
};
+ ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 6>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 4>;
+ reg = <0x01c21800 0x40>;
+ status = "disabled";
+ };
+
+ ir1: ir@01c21c00 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 7>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 6 4>;
+ reg = <0x01c21c00 0x40>;
+ status = "disabled";
+ };
+
lradc: lradc@01c22800 {
compatible = "allwinner,sun4i-lradc-keys";
reg = <0x01c22800 0x100>;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 2/5] [media] rc: add sunxi-ir driver
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
drivers/media/rc/Kconfig | 10 ++
drivers/media/rc/Makefile| 1 +
drivers/media/rc/sunxi-cir.c | 318 +++
3 files changed, 329 insertions(+)
create mode 100644 drivers/media/rc/sunxi-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8fbd377..9427fad 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -343,4 +343,14 @@ config RC_ST
If you're not sure, select N here.
+config IR_SUNXI
+tristate "SUNXI IR remote control"
+depends on RC_CORE
+depends on ARCH_SUNXI
+---help---
+ Say Y if you want to use sunXi internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called sunxi-ir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f8b54ff..9ee9ee7 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
+obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
new file mode 100644
index 000..5971b69
--- /dev/null
+++ b/drivers/media/rc/sunxi-cir.c
@@ -0,0 +1,318 @@
+/*
+ * Driver for Allwinner sunXi IR controller
+ *
+ * Copyright (C) 2014 Alexsey Shestacov
+ * Copyright (C) 2014 Alexander Bersenev
+ *
+ * Based on sun5i-ir.c:
+ * Copyright (C) 2007-2012 Daniel Wang
+ * Allwinner Technology Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_IR_DEV "sunxi-ir"
+
+/* Registers */
+/* IR Control */
+#define SUNXI_IR_CTL_REG 0x00
+/* Global Enable */
+#define REG_CTL_GENBIT(0)
+/* RX block enable */
+#define REG_CTL_RXEN BIT(1)
+/* CIR mode */
+#define REG_CTL_MD (BIT(4) | BIT(5))
+
+/* Rx Config */
+#define SUNXI_IR_RXCTL_REG0x10
+/* Pulse Polarity Invert flag */
+#define REG_RXCTL_RPPI BIT(2)
+
+/* Rx Data */
+#define SUNXI_IR_RXFIFO_REG 0x20
+
+/* Rx Interrupt Enable */
+#define SUNXI_IR_RXINT_REG0x2C
+/* Rx FIFO Overflow */
+#define REG_RXINT_ROI_EN BIT(0)
+/* Rx Packet End */
+#define REG_RXINT_RPEI_EN BIT(1)
+/* Rx FIFO Data Available */
+#define REG_RXINT_RAI_EN BIT(4)
+
+/* Rx FIFO available byte level */
+#define REG_RXINT_RAL(val)(((val) << 8) & (GENMASK(11, 8)))
+
+/* Rx Interrupt Status */
+#define SUNXI_IR_RXSTA_REG0x30
+/* RX FIFO Get Available Counter */
+#define REG_RXSTA_GET_AC(val) (((val) >> 8) & (GENMASK(5, 0)))
+/* Clear all interrupt status value */
+#define REG_RXSTA_CLEARALL0xff
+
+/* IR Sample Config */
+#define SUNXI_IR_CIR_REG 0x34
+/* CIR_REG register noise threshold */
+#define REG_CIR_NTHR(val)(((val) << 2) & (GENMASK(7, 2)))
+/* CIR_REG register idle threshold */
+#define REG_CIR_ITHR(val)(((val) << 8) & (GENMASK(15, 8)))
+
+/* Hardware supported fifo size */
+#define SUNXI_IR_FIFO_SIZE16
+/* How many messages in FIFO trigger IRQ */
+#define TRIGGER_LEVEL 8
+/* Required frequency for IR0 or IR1 clock in CIR mode */
+#define SUNXI_IR_BASE_CLK 800
+/* Frequency after IR internal divider */
+#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
+/* Sample period in ns */
+#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
+/* Noise threshold in samples */
+#define SUNXI_IR_RXNOISE 1
+/* Idle Threshold in samples */
+#define SUNXI_IR_RXIDLE 20
+/* Time after which device stops sending data in ms */
+#define SUNXI_IR_TIMEOUT 120
+
+struct sunxi_ir {
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem*base;
+ int irq;
+ struct clk *clk;
+ struct clk *apb_clk;
+ const char *map_name;
+};
+
+static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
+{
+ unsigned long status;
+ unsigned char dt;
+ unsigned int cnt, rc;
+ struct sunxi_ir *ir = dev_id;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ spin_lock(>ir_lock);
+
+ status =
[PATCH v9 0/5] ARM: sunxi: Add support for consumer infrared devices
This patch introduces Consumer IR(CIR) support for sunxi boards. This is based on Alexsey Shestacov's work based on the original driver supplied by Allwinner. Signed-off-by: Alexander Bersenev Signed-off-by: Alexsey Shestacov --- Changes since version 1: - Fix timer memory leaks - Fix race condition when driver unloads while interrupt handler is active - Support Cubieboard 2(need testing) Changes since version 2: - More reliable keydown events - Documentation fixes - Rename registers accurding to A20 user manual - Remove some includes, order includes alphabetically - Use BIT macro - Typo fixes Changes since version 3: - Split the patch on smaller parts - More documentation fixes - Add clock-names in DT - Use devm_clk_get function to get the clocks - Removed gpios property from ir's DT - Changed compatible from allwinner,sunxi-ir to allwinner,sun7i-a20-ir in DT - Use spin_lock_irq instead spin_lock_irqsave in interrupt handler - Add myself in the copyright ;) - Coding style and indentation fixes Changes since version 4: - Try to fix indentation errors by sending patches with git send-mail Changes since version 5: - More indentation fixes - Make patches pass checkpatch with --strict option - Replaced magic numbers with defines(patch by Priit Laes) - Fixed oops on loading(patch by Hans de Goede) Changes since version 6: - Removed constants from code - Better errrors handling on loading - Renamed sunxi-ir.c to sunxi-cir.c - Changed description of second commit - Order entries in dts and dtsi by register address - Code style fixes Changes since version 7: - Removed a couple of blank lines in code - Delay interrupts init until we are ready to handle them - Increased the reported duration of each pulse by one - Refactored defines Changes since version 8: - Split the DT patch to three - Code style fixes Alexander Bersenev (5): ARM: sunxi: Add documentation for sunxi consumer infrared devices [media] rc: add sunxi-ir driver ARM: sunxi: Add pins for IR controller on A20 to dtsi ARM: sunxi: Add IR controllers on A20 to dtsi ARM: sunxi: Enable IR controller on cubieboard 2 and cubietruck in dts .../devicetree/bindings/media/sunxi-ir.txt | 23 ++ arch/arm/boot/dts/sun7i-a20-cubieboard2.dts| 6 + arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 + arch/arm/boot/dts/sun7i-a20.dtsi | 32 +++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile | 1 + drivers/media/rc/sunxi-cir.c | 318 + 7 files changed, 396 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt create mode 100644 drivers/media/rc/sunxi-cir.c -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 1/5] ARM: sunxi: Add documentation for sunxi consumer infrared devices
This patch adds documentation for Device-Tree bindings for sunxi IR
controller.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
.../devicetree/bindings/media/sunxi-ir.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
new file mode 100644
index 000..014dd8b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
+
+Required properties:
+- compatible : should be "allwinner,sun7i-a20-ir";
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <_gates 6>, <_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 1>;
+ reg = <0x01C21800 0x40>;
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What can change in ways Linux handles memory when all memory >4G is disabled? (x86)
On Sun, Jun 8, 2014 at 9:53 PM, H. Peter Anvin wrote: > > This would point either to an iommu problem, or a problem in the driver > where addresses somehow get truncated to 32 bits. Since this is a > graphics driver it is extremely complex, and subtle problems could be > buried somewhere inside it. The fact that you can trigger it without a > driver would point to that kind of problem inside the firmware. > > -hpa My assumption is that in new BIOSes (old ones are working, as I've said, for T440p) there is some new way nvidia should be enabled, and it's not related to ACPI (the calls are same in Windows). There are no related changelog entries for T440p [1] (between 1.14 and 1.16). Also, about address truncation: I thought so too, but if I understand correctly, then some memory in >=4G region should be reserved for some driver's use, and this is not the case (see [2] for /proc/iomem). Nikolay Amiantov. [1]: http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/gluj13us.txt [2]: http://bpaste.net/show/355712/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Staging: speakup: ERROR: Fix macro parenthesis.
It looks like this patch is adding blank lines not parenthesis like the
subject says.
regards,
dan carpenter
On Sun, Jun 08, 2014 at 11:12:57PM +0900, Choi Gi-yong wrote:
> Signed-off-by: Choi Gi-yong
> ---
> drivers/staging/speakup/speakup_acntpc.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/speakup/speakup_acntpc.c
> b/drivers/staging/speakup/speakup_acntpc.c
> index 31f952b..f70b698 100644
> --- a/drivers/staging/speakup/speakup_acntpc.c
> +++ b/drivers/staging/speakup/speakup_acntpc.c
> @@ -35,7 +35,7 @@
> #include "speakup_acnt.h" /* local header file for Accent values */
>
> #define DRV_VERSION "2.10"
> -#define PROCSPEECH '\r'
> +#define PROCSPEECH ('\r')
>
> static int synth_probe(struct spk_synth *synth);
> static void accent_release(void);
> @@ -152,8 +152,10 @@ static inline bool synth_full(void)
> static const char *synth_immediate(struct spk_synth *synth, const char *buf)
> {
> u_char ch;
> +
> while ((ch = *buf)) {
> int timeout = SPK_XMITR_TIMEOUT;
> +
> if (ch == '\n')
> ch = PROCSPEECH;
> if (synth_full())
> @@ -257,6 +259,7 @@ static int synth_probe(struct spk_synth *synth)
> {
> unsigned int port_val = 0;
> int i = 0;
> +
> pr_info("Probing for %s.\n", synth->long_name);
> if (port_forced) {
> speakup_info.port_tts = port_forced;
> --
> 1.9.1
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What can change in ways Linux handles memory when all memory >4G is disabled? (x86)
On 06/06/2014 05:06 PM, Nikolay Amiantov wrote:
>
> I've played a bit with this theory in mind and found a very
> interesting thing -- when I reserve all memory upper than 4G with
> "memmap" kernel option ("memmap=99G$0x1"), everything works!
> Also, I've written a small utility that fills memory with zeros using
> /dev/mem and then checks it. I've checked reserved memory with it, and
> it appears that no memory in that region is corrupted at all, which is
> even more strange. I suspect that somehow when nvidia is enabled
> I/O-mapped memory regions are corrupted, and only when upper memory is
> not enabled. Also, memory map does not differ apart from missing last
> big chunk of memory with and without "memmap", and with Windows, too.
> If I enable even small chunk of "upper" memory (e.g.,
> 0x27000-0x28000), there are usual crashes.
>
> Long story short: I'm interested how memory management can differ when
> this "upper" memory regions are enabled?
>
This would point either to an iommu problem, or a problem in the driver
where addresses somehow get truncated to 32 bits. Since this is a
graphics driver it is extremely complex, and subtle problems could be
buried somewhere inside it. The fact that you can trigger it without a
driver would point to that kind of problem inside the firmware.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BISECTED][REGRESSION] Kernel does not boot on EeePC
On 06/08/2014 02:45 AM, Ingo Molnar wrote: > > * Sitsofe Wheeler wrote: > >> Hi, >> >> The latest kernel (c593e8978722f7f4a12932733cfeed6c0c74fbaa) refuses to >> boot on my EeePC - after grub is finished the screen just remains black >> and the only thing that does something is pressing the power button. The >> problem commit seems to be: >> >> commit 3e1a878b7ccdb31da6d9d2b855c72ad87afeba3f >> Author: Igor Mammedov >> Date: Thu Jun 5 15:42:45 2014 +0200 >> >> x86/smpboot: Initialize secondary CPU only if master CPU will wait for it > > Argh, and have read this just a minute after expressing my hope that > the hotplug fix is correct :-/ > > Linus, please revert commit 3e1a878b7ccdb. > > Acked-by: Ingo Molnar > I really want to say *THANK YOU* to Sitsofe for a very timely and complete report. You really saved us some highly valuable time. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
UPDATE YOUR WEBMAIL ACCOUNT NOW!
Attention User; Your email Quota is almost exceeded. Starting from June 8th, we are migrating to new email interface. So we are currently doing a maintenance on our server. Please, click the link below to Enter and update your account and avoid losing your inbox. http://convert2web.com/staff/allow.html Thank you, Technical Team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: per-thread wait_queue_t
On Sun, Jun 8, 2014 at 4:40 AM, Pavel Machek wrote: > > When you proposed to put wait queues into task_struct, you were > probably looking for less coding and more analysis? I'm ok with coding, I find your particular patch horrible. You add a dynamic allocator that will work *horribly* badly if people actually start using it for more complex cases, and then you use that for just about the least interesting case. And the way you do the dynamic allocator, nobody can ever allocate one of the wait-queue entries *efficiently* by just knowing that they are a leaf and there is never any recursive allocation. So quite frankly, I'd add *one* static wait-queue entry, and use it unconditionally (no "allocation" wrapper) in all the cases where we see that all that ever happens is And then I'd make ___wait_event() use that one statically allocated per-thread wait-queue instead of the current on-stack one. That would get a lot of users in one fell swoop. We might have to add some validation code that the "event" function cannot do anything that can in turn sleep, but that sounds fairly simple. See? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] lib/random32.c: Make prandom_u32_max efficient for powers of 2
On Sat, Jun 7, 2014, at 1:28, George Spelvin wrote:
> diff --git a/include/linux/random.h b/include/linux/random.h
> index 57fbbffd..e1f3ec9a 100644
> --- a/include/linux/random.h
> +++ b/include/linux/random.h
> @@ -47,11 +47,23 @@ void prandom_bytes_state(struct rnd_state *state, void
> *buf, int nbytes);
> * generator, that is, prandom_u32(). This is useful when requesting a
> * random index of an array containing ep_ro elements, for example.
> *
> + * If ep_ro is a power of 2 known at compile time, a modulo operation
> + * reduces to a simple mask to extract the low order bits. Otherwise,
> + * it uses a multiply and shift, which is faster than a general modulus.
> + *
> * Returns: pseudo-random number in interval [0, ep_ro)
> */
> static inline u32 prandom_u32_max(u32 ep_ro)
> {
> - return (u32)(((u64) prandom_u32() * ep_ro) >> 32);
> + /*
> + * Instead of just __builtin_constant_p(ep_ro), this test is
> + * "is it known at compile time that ep_ro is a power of 2?", and
> + * can in theory handle the case that it's an unknown power of 2.
> + */
> + if (__builtin_constant_p(ep_ro & (ep_ro-1)) && !(ep_ro & (ep_ro-1)))
> + return prandom_u32() & (ep_ro-1);
> + else
> + return (u32)((u64)prandom_u32() * ep_ro >> 32);
> }
Have you checked assembler output if this helps anything at all? Constant
propagation in the compiler should be able to figure that out all by itself.
The only places I use __builtin_constant_p today are where I also make use of
inline assembler.
Please check this as it makes the code more complicated and I doubt it is worth
it.
Btw, IIRC there is a function is_power_of_2 somewhere. ;)
Thanks,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: What can change in ways Linux handles memory when all memory >4G is disabled? (x86)
On Sun, Jun 8, 2014 at 8:19 AM, Bjorn Helgaas wrote: > [+cc linux-pci, linux-pm] > > > I don't know what ACPI methods you're calling, but (as I'm sure you > know) it's not guaranteed to be safe to call random methods because > they can make arbitrary changes to the system. Yes, I've tested this behaviour with bbswitch and nouveau's runpm separately, because of this -- this problem is persisting without any changes. > > > I skimmed through [1], but I'm not sure I understood everything. > Here's what I gleaned; please correct any mistaken impressions: > > 1) Suspend/resume is mentioned in [1], but the problem occurs even > without any suspend/resume. Yes, that's correct -- suspend/resume was mentioned because a lot of people observe this bug after bbswitch module they are using disables nvidia at boot and enables it again on suspend (I can't remember why it does this). When this happens, on resume user observes black screen, broken FS and so on. > 2) The problem happens on a completely stock untainted upstream > kernel even with no nvidia, nouveau, or i915 drivers loaded. It depends on what you call "stock" -- something in kernel is needed to trigger this behaviour, but I've tested it on ramdisk with only acpi_call module loaded (which is non-stock, but only allows to do arbitrary ACPI calls from userspace). This behaviour is same with nouveau+i915, too (which can be called stock), and with bbswitch (which can't be called so). > 3) Disabling the nvidia device (02:00.0) by executing an ACPI method > works fine, and the system works fine after the nvidia device is > disabled. Yes, the most popular "workaround" for this problem, giving you don't care about nvidia and only want to lower power consumption, is to use something like [1] (commented lines are calls how they are made in Windows). > 4) This ACPI method puts the nvidia device in D3cold state. Right, as far as I understood. > 5) Problems start when enabling the nvidia device by executing > another ACPI method. Again right, you can observe an example in [2]. > > In the D3cold state, the PCI device is entirely powered off. After it > is re-enabled, e.g., by the ACPI method in 5) above, the device needs > to be completely re-initialized. Since you're executing the ACPI > method "by hand," outside the context of the Linux power management > system, there's nothing to re-initialize the device. > > This by itself shouldn't be a problem; the device should power up with > its BARs zeroed out and disabled, bus mastering disabled, etc. > > BUT the kernel doesn't know about these power changes you're making, > so some things will be broken. For example, while the nvidia device > is in D3cold, lspci will return garbage for that device. After it > returns to D0, lspci should work again, but now the state of the > device (BAR assignments, interrupts, etc.) is different from what > Linux thinks it is. > > If a driver does anything with the device after it returns to D0, I > think things will break, because the PCI core already knows what > resources are assigned to the device, but the device forgot them when > it was powered off. So the PCI core would happily enable the device > but it will respond at the wrong addresses. Thanks for the explanations! I don't really know much about PCI or Linux PCI subsystem internals, only some general theory, including memory I/O and power states. This doesn't, however, explain why does this bug is observable even with nouveau's proper dynpm or bbswitch. I've looked through the source of bbswitch [3], and, AFAIU, it differs from raw calls in those ways: 1) It calls only _DSM ACPI routine and then disables the device by issuing calls on lines 260-277 (it saves some state and puts device to D3 from what I can tell, maybe it will tell more to you). 2) It doesn't use ACPI at all for enabling the card, only puts device to D0 again, restores state and sets something (lines 292-296). > > But I think you said problems happen even without any driver for the > nvidia device, so there's probably more going on. This is a video > device, and I wouldn't be surprised if there's some legacy VGA > behavior that doesn't follow the usual PCI rules. > > Can you: > > 1) Collect complete "lspci -vvxxx" output from the whole system, with > the nvidia card enabled. > 2) Disable nvidia card. > 3) Collect complete dmesg log. > 4) Try "lspci -s02:00.0". I expect this to show garbage if the nvidia > card is powered off. >From what I have understood, you have wanted me to do this with raw ACPI calls, not with other methods, correct? > 5) Enable nvidia card. > 6) Try "lspci -vvxxx" again. You mentioned changes to devices other > than nvidia, which sounds suspicious. > 7) Collect dmesg log again. I don't expect changes here, because the > kernel probably doesn't notice the power transition. There are some problems with (5..7), because after nvidia is enabled again, the system goes berserk with no way to do some output besides,
Re: [GIT PULL] x86/vdso changes for v3.16
On Fri, Jun 06, 2014 at 02:07:11PM -0700, H. Peter Anvin wrote: > On 06/06/2014 02:00 PM, Andrew Morton wrote: > > On Wed, 4 Jun 2014 15:35:42 -0700 "H. Peter Anvin" > > wrote: > > > >> Vdso cleanups and improvements largely from Andy Lutomirski. > > > > arch/x86/vdso/vdso2c.h: In function 'go64': > > arch/x86/vdso/vdso2c.h:21: warning: implicit declaration of function > > 'le64toh' > > arch/x86/vdso/vdso2c.h:21: warning: implicit declaration of function > > 'le32toh' > > arch/x86/vdso/vdso2c.h:21: warning: implicit declaration of function > > 'le16toh' > > arch/x86/vdso/vdso2c.h:119: warning: implicit declaration of function > > 'htole16' > > > > My Fedora Core 6 (lol gotcha) test box doesn't have these. > > > > http://www.unix.com/man-page/linux/3/le64toh/ has some details. I > > don't appear to have letoh64 and friends either. > > > > OK... so now we have a tools baseline problem. It isn't that we > couldn't open-code these functions, but of course we'd also like to not > *have* to do so... but also we don't want to have the kernel build rely > on autoconf ;) > > So we have a few options, here: > > 1. We could use the unaligned macros defined in >tools/include/tools/*_byteshift.h. > > 2. Open-code it. > > 3. Define a baseline which includes these kinds of functions. > > I guess I would be leaning toward #1, but would also wonder if that also > means we should add -I$(srctree)/tools/include to the global settings > ... we are *already* adding it to HOSTCFLAGS_sortextable.o. I would say that tools/include/tools/* should be considered the baseline for programs running on the host. So therefore unconditionally adding -I$(srctree)/tools/include should then be OK. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: tile: kernel: unaligned.c: Cleaning up uninitialized variables
Hi Chris So uint max was a better default value. Yeah, good it came into use. The main thing that the code got a proper review :) Kind regards Rickard Strandqvist 2014-06-08 3:41 GMT+02:00 Chris Metcalf : > On 5/31/2014 7:00 PM, Rickard Strandqvist wrote: >> >> There is a risk that the variable will be used without being initialized. >> >> This was largely found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist >> --- >> arch/tile/kernel/unaligned.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > > Thanks! Taken into the tile tree with some slight modifications (initialize > variables to -1 not 0, and remove the resulting dead code in find_regs). > > -- > Chris Metcalf, Tilera Corp. > http://www.tilera.com > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] checkpatch: fix complex macro false positive for escaped constant char
A single escaped constant char is not a complex macro.
Signed-off-by: Joe Perches
---
On Sun, 2014-06-08 at 23:12 +0900, Choi Gi-yong wrote:
> diff --git a/drivers/staging/speakup/speakup_acntpc.c
> b/drivers/staging/speakup/speakup_acntpc.c
[]
> @@ -35,7 +35,7 @@
[]
> -#define PROCSPEECH '\r'
> +#define PROCSPEECH ('\r')
checkpatch false positive, doesn't need parenthesis
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 010b18e..ba92493 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3757,7 +3757,7 @@ sub process {
$dstat !~ /^(?:$Ident|-?$Constant),$/ &&
# 10, // foo(),
$dstat !~ /^(?:$Ident|-?$Constant);$/ &&
# foo();
$dstat !~ /^[!~-]?(?:$Lval|$Constant)$/ &&
# 10 // foo() // !foo // ~foo // -foo // foo->bar // foo.bar->baz
- $dstat !~ /^'X'$/ &&
# character constants
+ $dstat !~ /^'X'$/ && $dstat !~ /^'XX'$/ &&
# character constants
$dstat !~ /$exceptions/ &&
$dstat !~ /^\.$Ident\s*=/ &&
# .foo =
$dstat !~ /^(?:\#\s*$Ident|\#\s*$Constant)\s*$/ &&
# stringification #foo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: wireless: rtlwifi: rtl8192de: hw.c: Cleaning up conjunction always evaluates to false
On 06/08/2014 05:43 AM, Peter Wu wrote: On Sunday 08 June 2014 12:36:11 Rickard Strandqvist wrote: Then we use MSR_MASK instead, new patch then. But I will wait a day? Or what is long enough to be sure that nobody else have any objections? How is this usually resolved? Well, Larry is the maintainer, so he will ultimately pick up patches. One or two days should give people some time to read and reply. My role as maintainer is a little different than others. As I have a private broadband connection with only 1 Mbps upload, it is not practical for me to operate a git server. I used to have an account at kernel.org, but I lost it after the break-in there. As I have never met face-to-face with another Linux developer, I have had no chance to have my credentials signed, so that resource is unavailable. As a result, I ACK or NACK patches and they are picked up by John Linville for drivers in the regular wireless tree, and Greg Kroah-Hartman for the staging drivers. As for MSR_MASK, that macro does not exist yet, I was wondering whether it's OK to add a new macro? (Larry?) Yes, that is OK. Sure, I can send a patch for all the files instead. However, earlier received complaints when I sent patches extending over more than one file. These do really need to be split a little. There must be at least one patch for the wireless tree, and a second for staging. In fact, I prefer the way they are with one for each driver. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] regulator: ab8500: Remove ab8500_regulator_debug_init/exit()
CONFIG_REGULATOR_AB8500_DEBUG is always not defined.
ab8500_regulator_debug_init() is not called at all now,
ab8500_regulator_debug_exit() simply return 0, thus remove them.
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 13 -
include/linux/regulator/ab8500.h | 14 --
2 files changed, 27 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index 88da8626..1fda14e 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -3071,21 +3071,8 @@ static int ab8500_regulator_probe(struct platform_device
*pdev)
return 0;
}
-static int ab8500_regulator_remove(struct platform_device *pdev)
-{
- int err;
-
- /* remove regulator debug */
- err = ab8500_regulator_debug_exit(pdev);
- if (err)
- return err;
-
- return 0;
-}
-
static struct platform_driver ab8500_regulator_driver = {
.probe = ab8500_regulator_probe,
- .remove = ab8500_regulator_remove,
.driver = {
.name = "ab8500-regulator",
.owner = THIS_MODULE,
diff --git a/include/linux/regulator/ab8500.h b/include/linux/regulator/ab8500.h
index 7530744..d8ecefa 100644
--- a/include/linux/regulator/ab8500.h
+++ b/include/linux/regulator/ab8500.h
@@ -322,18 +322,4 @@ struct ab8500_regulator_platform_data {
struct regulator_init_data *ext_regulator;
};
-#ifdef CONFIG_REGULATOR_AB8500_DEBUG
-int ab8500_regulator_debug_init(struct platform_device *pdev);
-int ab8500_regulator_debug_exit(struct platform_device *pdev);
-#else
-static inline int ab8500_regulator_debug_init(struct platform_device *pdev)
-{
- return 0;
-}
-static inline int ab8500_regulator_debug_exit(struct platform_device *pdev)
-{
- return 0;
-}
-#endif
-
#endif
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] regulator: ab8500: Remove ab8500_regulator_of_probe()
Now this is a DT-only driver because non-devicetree probe path is removed,
so merge ab8500_regulator_of_probe() into ab8500_regulator_probe().
Signed-off-by: Axel Lin
---
drivers/regulator/ab8500.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/drivers/regulator/ab8500.c b/drivers/regulator/ab8500.c
index c625468..88da8626 100644
--- a/drivers/regulator/ab8500.c
+++ b/drivers/regulator/ab8500.c
@@ -3037,28 +3037,12 @@ static int ab8500_regulator_register(struct
platform_device *pdev,
return 0;
}
-static int
-ab8500_regulator_of_probe(struct platform_device *pdev,
- struct device_node *np)
-{
- struct of_regulator_match *match = abx500_regulator.match;
- int err, i;
-
- for (i = 0; i < abx500_regulator.info_size; i++) {
- err = ab8500_regulator_register(
- pdev, match[i].init_data, i, match[i].of_node);
- if (err)
- return err;
- }
-
- return 0;
-}
-
static int ab8500_regulator_probe(struct platform_device *pdev)
{
struct ab8500 *ab8500 = dev_get_drvdata(pdev->dev.parent);
struct device_node *np = pdev->dev.of_node;
- int err;
+ struct of_regulator_match *match;
+ int err, i;
if (!ab8500) {
dev_err(>dev, "null mfd parent\n");
@@ -3075,7 +3059,16 @@ static int ab8500_regulator_probe(struct platform_device
*pdev)
"Error parsing regulator init data: %d\n", err);
return err;
}
- return ab8500_regulator_of_probe(pdev, np);
+
+ match = abx500_regulator.match;
+ for (i = 0; i < abx500_regulator.info_size; i++) {
+ err = ab8500_regulator_register(pdev, match[i].init_data, i,
+ match[i].of_node);
+ if (err)
+ return err;
+ }
+
+ return 0;
}
static int ab8500_regulator_remove(struct platform_device *pdev)
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Staging: speakup: ERROR: Fix macro parenthesis.
Signed-off-by: Choi Gi-yong
---
drivers/staging/speakup/speakup_acntpc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/speakup_acntpc.c
b/drivers/staging/speakup/speakup_acntpc.c
index 31f952b..f70b698 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -35,7 +35,7 @@
#include "speakup_acnt.h" /* local header file for Accent values */
#define DRV_VERSION "2.10"
-#define PROCSPEECH '\r'
+#define PROCSPEECH ('\r')
static int synth_probe(struct spk_synth *synth);
static void accent_release(void);
@@ -152,8 +152,10 @@ static inline bool synth_full(void)
static const char *synth_immediate(struct spk_synth *synth, const char *buf)
{
u_char ch;
+
while ((ch = *buf)) {
int timeout = SPK_XMITR_TIMEOUT;
+
if (ch == '\n')
ch = PROCSPEECH;
if (synth_full())
@@ -257,6 +259,7 @@ static int synth_probe(struct spk_synth *synth)
{
unsigned int port_val = 0;
int i = 0;
+
pr_info("Probing for %s.\n", synth->long_name);
if (port_forced) {
speakup_info.port_tts = port_forced;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 25/26] staging: rtl8188eu: Remove unused function nat25_handle_frame()
Signed-off-by: navin patidar
---
V2:
Restore sequence of source code compilation, sequence was changed by v1
of this patch.
drivers/staging/rtl8188eu/core/rtw_br_ext.c| 61
drivers/staging/rtl8188eu/include/recv_osdep.h |1 -
2 files changed, 62 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
index 9d9e89a..70b8f07 100644
--- a/drivers/staging/rtl8188eu/core/rtw_br_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_br_ext.c
@@ -1030,67 +1030,6 @@ int nat25_db_handle(struct adapter *priv, struct sk_buff
*skb, int method)
return -1;
}
-int nat25_handle_frame(struct adapter *priv, struct sk_buff *skb)
-{
- if (!(skb->data[0] & 1)) {
- int is_vlan_tag = 0, i, retval = 0;
- unsigned short vlan_hdr = 0;
- unsigned short protocol;
-
- protocol = be16_to_cpu(*((__be16 *)(skb->data + 2 * ETH_ALEN)));
- if (protocol == ETH_P_8021Q) {
- is_vlan_tag = 1;
- vlan_hdr = *((unsigned short
*)(skb->data+ETH_ALEN*2+2));
- for (i = 0; i < 6; i++)
- *((unsigned short
*)(skb->data+ETH_ALEN*2+2-i*2)) = *((unsigned short
*)(skb->data+ETH_ALEN*2-2-i*2));
- skb_pull(skb, 4);
- }
-
- if (!priv->ethBrExtInfo.nat25_disable) {
- spin_lock_bh(>br_ext_lock);
- /*
-* This function look up the destination network
address from
-* the NAT2.5 database. Return value = -1 means
that the
-* corresponding network protocol is NOT support.
-*/
- if (!priv->ethBrExtInfo.nat25sc_disable &&
- (be16_to_cpu(*((__be16 *)(skb->data+ETH_ALEN*2)))
== ETH_P_IP) &&
- !memcmp(priv->scdb_ip, skb->data+ETH_HLEN+16, 4)) {
- memcpy(skb->data, priv->scdb_mac, ETH_ALEN);
-
- spin_unlock_bh(>br_ext_lock);
- } else {
- spin_unlock_bh(>br_ext_lock);
-
- retval = nat25_db_handle(priv, skb,
NAT25_LOOKUP);
- }
- } else {
- if (((be16_to_cpu(*((__be16 *)(skb->data+ETH_ALEN*2)))
== ETH_P_IP) &&
- !memcmp(priv->br_ip, skb->data+ETH_HLEN+16, 4)) ||
- ((be16_to_cpu(*((__be16 *)(skb->data+ETH_ALEN*2)))
== ETH_P_ARP) &&
- !memcmp(priv->br_ip, skb->data+ETH_HLEN+24, 4))) {
- /* for traffic to upper TCP/IP */
- retval = nat25_db_handle(priv, skb,
NAT25_LOOKUP);
- }
- }
-
- if (is_vlan_tag) {
- skb_push(skb, 4);
- for (i = 0; i < 6; i++)
- *((unsigned short *)(skb->data+i*2)) =
*((unsigned short *)(skb->data+4+i*2));
- *((__be16 *)(skb->data+ETH_ALEN*2)) =
__constant_htons(ETH_P_8021Q);
- *((unsigned short *)(skb->data+ETH_ALEN*2+2)) =
vlan_hdr;
- }
-
- if (retval == -1) {
- /* DEBUG_ERR("NAT25: Lookup fail!\n"); */
- return -1;
- }
- }
-
- return 0;
-}
-
#define SERVER_PORT67
#define CLIENT_PORT68
#define DHCP_MAGIC 0x63825363
diff --git a/drivers/staging/rtl8188eu/include/recv_osdep.h
b/drivers/staging/rtl8188eu/include/recv_osdep.h
index a4fd957..a52a696 100644
--- a/drivers/staging/rtl8188eu/include/recv_osdep.h
+++ b/drivers/staging/rtl8188eu/include/recv_osdep.h
@@ -46,7 +46,6 @@ int rtw_os_recvbuf_resource_alloc(struct adapter *adapt,
struct recv_buf *buf);
void rtw_os_read_port(struct adapter *padapter, struct recv_buf *precvbuf);
void rtw_init_recv_timer(struct recv_reorder_ctrl *preorder_ctrl);
-int nat25_handle_frame(struct adapter *priv, struct sk_buff *skb);
int _netdev_open(struct net_device *pnetdev);
int netdev_open(struct net_device *pnetdev);
int netdev_close(struct net_device *pnetdev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
safety of *mutex_unlock() (Was: [BUG] signal: sighand unprotected when accessed by /proc)
On 06/06, Paul E. McKenney wrote: > > On Tue, Jun 03, 2014 at 10:01:25PM +0200, Oleg Nesterov wrote: > > > > I'll try to recheck rt_mutex_unlock() tomorrow. _Perhaps_ rcu_read_unlock() > > should be shifted from lock_task_sighand() to unlock_task_sighand() to > > ensure that rt_mutex_unlock() does nothihg with this memory after it > > makes another lock/unlock possible. > > > > But if we need this (currently I do not think so), this doesn't depend on > > SLAB_DESTROY_BY_RCU. And, at first glance, in this case > > rcu_read_unlock_special() > > might be wrong too. > > OK, I will bite... What did I mess up in rcu_read_unlock_special()? > > This function does not report leaving the RCU read-side critical section > until after its call to rt_mutex_unlock() has returned, so any RCU > read-side critical sections in rt_mutex_unlock() will be respected. Sorry for confusion. I only meant that afaics rcu_read_unlock_special() equally depends on the fact that rt_mutex_unlock() does nothing with "struct rt_mutex" after it makes another rt_mutex_lock() + rt_mutex_unlock() possible, otherwise this code is wrong (and unlock_task_sighand() would be wrong too). Just to simplify the discussion... suppose we add "atomic_t nr_slow_unlock" into "struct rt_mutex" and change rt_mutex_slowunlock() to do atomic_inc(>nr_slow_unlock) after it drops ->wait_lock. Of course this would be ugly, just for illustration. In this case atomic_inc() above can write to rcu_boost()'s stack after this functions returns to the caller. And unlock_task_sighand() would be wrong too, atomic_inc() could write to the memory which was already returned to system because "unlock" path runs outside of rcu-protected section. But it seems to me that currently we are safe, rt_mutex_unlock() doesn't do something like this, a concurrent rt_mutex_lock() must always take wait_lock too. And while this is off-topic and I can be easily wrong, it seems that the normal "struct mutex" is not safe in this respect. If nothing else, once __mutex_unlock_common_slowpath()->__mutex_slowpath_needs_to_unlock() sets lock->count = 1, a concurent mutex_lock() can take and then release this mutex before __mutex_unlock_common_slowpath() takes ->wait_lock. So _perhaps_ we should not rely on this property of rt_mutex "too much". Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: Add a defer reset object to send board specific reset
On Sun, Jun 8, 2014 at 10:09 AM, Houcheng Lin wrote:
> The Problem
> ---
> The reset signal on a hardware board is send either:
> - during machine initialization
> - during bus master's initialization
>
> In some hardware design, devices on bus need a non-standard and extra reset
> signal after bus is initialied. Most reason is to wake up device from hanging
> state.
>
> The board spefic reset code can not be put into machine init code, as it is
> too early. This code can not also be put onto chip's driver, as it is board
> specific and not suitable for a common chip driver.
>
> Defer Reset Object
> --
> The defer reset object is to resolve this issue, developer can put a defer-
> reset device on the board's dts file and enable DEFER RESET OBJECT CONFIG.
> During driver init-calls, a defer-reset object is created and issue reset
> signal
> after the enclosing device is initialized.
>
> This eliminate the need to rewrite a driver module with only one purpose:
> sending
> a board specific reset. This also allow mainstream kernel to support many
> boards
> that modify the common drivers to send board specific reset. Configuring
> defer-reset
> device in dts leave the board specific reset rules on board level and simple
> to
> maintain.
Interesting approach to a long-standing problem. I had my own
embarrassing attempt at it (power sequences), and more recently Olof
(CC'd) sent something related for the MMC bus
(http://www.spinics.net/lists/devicetree/msg18900.html - I'm not sure
what has become of this patch?). And there are certainly other
attempts that I don't know of.
So, let's say that this time we do it for real. There are some points
I like in your approach, like the fact that it is completely
bus-agnostic. But although it will certainly not end up being as
controversial as the power sequences have been, I am not sure
everybody will agree to use the DT this way...
>
> Example dts File
>
> usb-ehci-chip@1211000{
> usb-phy = <_phy>;
> defer_reset_vbus {
> compatible = "defer-reset";
> reset-gpios = < 5 1>;
> reset-init = <0>;
> reset-end = <1>;
> delay = <5>;
> };
> };
Here I am not convinced that everybody will like the fact that this
appears as a device of its own, with its own compatible property.
Let's see what the DT people think of it.
>
> Block Diagram of dts File
> -
> +-+
> | usb-ehci-chip@1211000 |
> | +-+ |
> | | defer-reset(gpx3) | |
> | +-+ |
> +-+
>
> Signed-off-by: Houcheng Lin
> ---
> drivers/gpio/Kconfig| 8 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-defer-reset.c | 179
>
> 3 files changed, 188 insertions(+)
> create mode 100644 drivers/gpio/gpio-defer-reset.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index a86c49a..99aa0d6 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -851,6 +851,14 @@ config GPIO_BCM_KONA
> help
> Turn on GPIO support for Broadcom "Kona" chips.
>
> +config GPIO_DEFER_RESET
> + bool "Defer reset driver via gpio"
> + depends on OF_GPIO
> + help
> + Enable defer reset drvier
s/drvier/driver
> + The reset signal would be issued after a device on USB or PCI bus
> is initialied.
s/initialied/initialized
> + The dependency of reset signal and device can be specified in
> board's dts file.
> +
> comment "USB GPIO expanders:"
>
> config GPIO_VIPERBOARD
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 6309aff..0754758 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -101,3 +101,4 @@ obj-$(CONFIG_GPIO_WM8994) += gpio-wm8994.o
> obj-$(CONFIG_GPIO_XILINX) += gpio-xilinx.o
> obj-$(CONFIG_GPIO_XTENSA) += gpio-xtensa.o
> obj-$(CONFIG_GPIO_ZEVIO) += gpio-zevio.o
> +obj-$(CONFIG_GPIO_DEFER_RESET) += gpio-defer-reset.o
> diff --git a/drivers/gpio/gpio-defer-reset.c b/drivers/gpio/gpio-defer-reset.c
> new file mode 100644
> index 000..c6decab
> --- /dev/null
> +++ b/drivers/gpio/gpio-defer-reset.c
> @@ -0,0 +1,179 @@
> +/*
> + * GPIO Defer Reset Driver
> + *
> + * Copyright (C) 2014 Houcheng Lin
> + * Author: Houcheng Lin
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
Re: [PATCH 6/7] lib/random32.c: Randomize timeout to the millisecond, not the second
> Note, when you talk about efficiency here, this is called once every > 40+ secs ... ;) Agreed, in this case the code size saving (avoid a function call) is the main benefit. And I prefer to avoid inefficiency on general priinciples, if it's not serving some other goal. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] lib/random32.c: Use instead of hand-rolling it
> Seems fine by me, since it's random anyway archs might not care > about the *_le32, though this might yield additional work in some > cases I presume. If you think that's okay, sure. I kept it consistent to get byte-for-byte identical results. If variations in that are allowed, that can also simplify the trailing storage case: + if (bytes & 2) + put_unaligned_le16((u16)random, p+i); + if (bytes & 1) + p[i+bytes-1] = (u8)(random >> 16); >> +for (i = 0; i < round_down(bytes, sizeof(u32)); i += sizeof(u32)) >> +put_unaligned_le32(prandom_u32_state(state), p+i); > Nit: 'p + i' I don't really care, but I'm happy without the spaces; I add them to show what binds more weakly, and in this case that's the argument-separating comma. >> +p[i] = (u8)random; > Nit: '(u8) random' Actually, my style and most of the kerel is to not put a space in a cast, since it binds so tighty. E.g. compare git grep ')[a-z]' kernel/ git grep ') [a-z]' kernel/ Notice that the second is alsmost all comments. (There are some spaces in kernel/ptrace.v.) I'd rather leave it without the space unless you feel very strongly about it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] lib/random32.c: Randomize timeout to the millisecond, not the second
On 06/08/2014 01:30 PM, George Spelvin wrote: Fine by me this cleanup, although not strictly needed. Agreed. The timer slack is set to HZ (1 second) anyway. It just dawned on me that a simpler and more efficient way to do this (which I'll do in v2 of this) would be: Note, when you talk about efficiency here, this is called once every 40+ secs ... ;) /* reseed every ~60 seconds, in [40 .. 80) interval with slack */ - expires = 40 + (prandom_u32() % 40); - seed_timer.expires = jiffies + msecs_to_jiffies(expires * MSEC_PER_SEC); + expires = 40*HZ + prandom_u32_max(40*HZ); + seed_timer.expires = jiffies + expires; That avoids calling msecs_to_jiffies entirely. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] lib/random32.c: Replace an #ifdef with a stub prandom_state_selftest()
>> #ifdef CONFIG_RANDOM32_SELFTEST >> static void __init prandom_state_selftest(void); >> +#else >> +#define prandom_state_selftest() (void)0 > Fine by me. I think you can remove this '(void)0' here, though. That's the standard way to write a no-op statement in C. I seem to recall there's a reason that the empty string can cause problems in some syntactic contexts, but I can't figure out what the situation is. At first, I thought of the obvious: if (condition) prandom_state_selftest(); unconditional_code(); ... but the semicolon makes that work. I'll try to remember the reason. (I know that nobody uses it in any such context, but it's good manners to make a function-like macro behave as exactly like a function as possible.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] lib/random32.c: Use instead of hand-rolling it
On 06/07/2014 10:25 AM, George Spelvin wrote:
The functions exist for a reason; the manual byte-at-a-time code
is unnecessarily slow (and bloated).
Signed-off-by: George Spelvin
Seems fine by me, since it's random anyway archs might not care
about the *_le32, though this might yield additional work in some
cases I presume.
---
lib/random32.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index e8f3557b..eee60100 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_RANDOM32_SELFTEST
static void __init prandom_state_selftest(void);
@@ -97,25 +98,23 @@ EXPORT_SYMBOL(prandom_u32);
*/
void prandom_bytes_state(struct rnd_state *state, void *buf, int bytes)
{
- unsigned char *p = buf;
+ u8 *p = buf;
int i;
- for (i = 0; i < round_down(bytes, sizeof(u32)); i += sizeof(u32)) {
- u32 random = prandom_u32_state(state);
- int j;
+ for (i = 0; i < round_down(bytes, sizeof(u32)); i += sizeof(u32))
+ put_unaligned_le32(prandom_u32_state(state), p+i);
Nit: 'p + i'
- for (j = 0; j < sizeof(u32); j++) {
- p[i + j] = random;
- random >>= BITS_PER_BYTE;
- }
- }
if (i < bytes) {
u32 random = prandom_u32_state(state);
- for (; i < bytes; i++) {
- p[i] = random;
- random >>= BITS_PER_BYTE;
+ if (bytes & 2) {
+ put_unaligned_le16((u16)random, p+i);
Ditto.
+ if ((bytes & 1) == 0)
+ return;
+ i += 2;
+ random >>= 16;
}
+ p[i] = (u8)random;
Nit: '(u8) random'
You could probably use a switch statement with fall-through for
filling the remaining stuff, might simplify it further, perhaps.
}
}
EXPORT_SYMBOL(prandom_bytes_state);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] lib/random32.c: Remove excess calls to prandom_u32_state in initialization
Thank you for your time and attention on all these comments. > Fine by me although we simply resembled initialization code from > GSL here. I think that your subject line is a bit misleading though. Yes, I had a hard time coming up with a good summary. I'm removing *static* calls but not dynamic ones. How about "don't unroll one-time initialization code"? Would that be a better way to put it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] lib/random32.c: Replace an #ifdef with a stub prandom_state_selftest()
On 06/07/2014 10:22 AM, George Spelvin wrote:
The preferred Linux style for optional features is to define
no-op stub functions rather than wrap each call site in #ifdef.
Signed-off-by: George Spelvin
---
lib/random32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index 2e7c15c0..e8f3557b 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -40,6 +40,8 @@
#ifdef CONFIG_RANDOM32_SELFTEST
static void __init prandom_state_selftest(void);
+#else
+#define prandom_state_selftest() (void)0
Fine by me. I think you can remove this '(void)0' here, though.
#endif
static DEFINE_PER_CPU(struct rnd_state, net_rand_state);
@@ -188,9 +190,7 @@ static int __init prandom_init(void)
{
int i;
-#ifdef CONFIG_RANDOM32_SELFTEST
prandom_state_selftest();
-#endif
for_each_possible_cpu(i) {
struct rnd_state *state = _cpu(net_rand_state,i);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
On Thu, Jun 5, 2014 at 3:22 AM, abdoulaye berthe wrote:
> This avoids handling gpiochip remove error in device
> remove handler.
>
> Signed-off-by: abdoulaye berthe
> ---
> drivers/gpio/gpiolib.c | 24 +++-
> include/linux/gpio/driver.h | 2 +-
> 2 files changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index f48817d..022543f 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1263,10 +1263,9 @@ static void gpiochip_irqchip_remove(struct gpio_chip
> *gpiochip);
> *
> * A gpio_chip with any GPIOs still requested may not be removed.
> */
> -int gpiochip_remove(struct gpio_chip *chip)
> +void gpiochip_remove(struct gpio_chip *chip)
> {
> unsigned long flags;
> - int status = 0;
> unsignedid;
>
> acpi_gpiochip_remove(chip);
> @@ -1278,24 +1277,15 @@ int gpiochip_remove(struct gpio_chip *chip)
> of_gpiochip_remove(chip);
>
> for (id = 0; id < chip->ngpio; id++) {
> - if (test_bit(FLAG_REQUESTED, >desc[id].flags)) {
> - status = -EBUSY;
> - break;
> - }
> - }
> - if (status == 0) {
> - for (id = 0; id < chip->ngpio; id++)
> - chip->desc[id].chip = NULL;
> -
> - list_del(>list);
> + if (test_bit(FLAG_REQUESTED, >desc[id].flags))
> + panic("gpio: removing gpiochip with gpios still
> requested\n");
Really, really I don't think we should panic here. Apparently if you
don't do this things are going to crash later on some platforms. Could
you detail what the problem is exactly so we can try and come with a
solution?
Event if we crash later with a more obscure reason, using pr_err()
here to provide some information should be helpful enough.
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] lib/random32.c: Remove excess calls to prandom_u32_state in initialization
On 06/07/2014 10:20 AM, George Spelvin wrote:
Unrolling code in single-use code paths is just silly. There are two
instances:
1) prandom_warmup() calls 10 times.
2) prandom_state_selftest() can avoid one call and simplify the
loop logic by repeating an assignment to a local variable
(that probably adds zero code anyway)
Signed-off-by: George Spelvin
Fine by me although we simply resembled initialization code from
GSL here. I think that your subject line is a bit misleading though.
---
lib/random32.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/lib/random32.c b/lib/random32.c
index 4da5d281..2e7c15c0 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -134,17 +134,11 @@ EXPORT_SYMBOL(prandom_bytes);
static void prandom_warmup(struct rnd_state *state)
{
+ int i;
+
/* Calling RNG ten times to satify recurrence condition */
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
- prandom_u32_state(state);
+ for (i = 0; i < 10; i++)
+ prandom_u32_state(state);
}
static void prandom_seed_very_weak(struct rnd_state *state, u32 seed)
@@ -433,14 +427,15 @@ static void __init prandom_state_selftest(void)
for (i = 0; i < ARRAY_SIZE(test2); i++) {
struct rnd_state state;
+ u32 result;
prandom_seed_very_weak(, test2[i].seed);
prandom_warmup();
- for (j = 0; j < test2[i].iteration - 1; j++)
- prandom_u32_state();
+ for (j = 0; j < test2[i].iteration; j++)
+ result = prandom_u32_state();
- if (test2[i].result != prandom_u32_state())
+ if (test2[i].result != result)
errors++;
runs++;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] lib/random32.c: Mark self-test data as __initconst
On 06/07/2014 10:19 AM, George Spelvin wrote: So it can be thrown away along with the code that uses it. Signed-off-by: George Spelvin Fine by me. Acked-by: Daniel Borkmann -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
