Re: [PATCH 3/6] perf, tools, stat: Support metrics in --per-core/socket mode
On Wed, Feb 17, 2016 at 02:44:02PM -0800, Andi Kleen wrote:
SNIP
>
> perf_stat__print_shadow_stats(counter, uval,
> stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
> - cpu_map__id_to_cpu(id),
> + first_shadow_cpu(counter, id),
> &out);
> -
> if (!csv_output) {
> print_noise(counter, noise);
> print_running(run, ena);
> }
> }
>
> +static void aggr_update_shadow(void)
> +{
> + int cpu, cpu2, s2, id, s;
> + u64 val;
> + struct perf_evsel *counter;
> +
> + for (s = 0; s < aggr_map->nr; s++) {
> + id = aggr_map->map[s];
> + evlist__for_each(evsel_list, counter) {
> + val = 0;
> + for (cpu = 0; cpu < perf_evsel__nr_cpus(counter);
> cpu++) {
> + cpu2 = perf_evsel__cpus(counter)->map[cpu];
> + s2 = aggr_get_id(evsel_list->cpus, cpu2);
I think you need to pass cpu's 'idx' into aggr_get_id,
because it will do evsel_list->cpus[cpu2] for you
jirka
Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Sun, Feb 21, 2016 at 03:10:30PM +0200, Michael S. Tsirkin wrote: > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote: > > > > > > > > > +#if !(defined(FW_CFG_CTRL_OFF) && defined(FW_CTRL_DATA_OFF)) > > > > +# if (defined(CONFIG_ARM) || defined(CONFIG_ARM64)) > > > > +# define FW_CFG_CTRL_OFF 0x08 > > > > +# define FW_CFG_DATA_OFF 0x00 > > > > +# elif (defined(CONFIG_PPC_PMAC) || defined(CONFIG_SPARC32)) /* > > > > ppc/mac,sun4m */ > > > > +# define FW_CFG_CTRL_OFF 0x00 > > > > +# define FW_CFG_DATA_OFF 0x02 > > > > +# elif (defined(CONFIG_X86) || defined(CONFIG_SPARC64)) /* x86, sun4u > > > > */ > > > > +# define FW_CFG_CTRL_OFF 0x00 > > > > +# define FW_CFG_DATA_OFF 0x01 > > > > +# else > > > > +# warning "QEMU FW_CFG may not be available on this architecture!" > > > > +# define FW_CFG_CTRL_OFF 0x00 > > > > +# define FW_CFG_DATA_OFF 0x01 > > > > > > Better not try hacks like this, they are hard > > > to support down the road. Please only list what is tested and > > > actually exposed by QEMU. > > > > I was looking for a standard way to advertise register offsets within > > the ioport or mmio region assigned to fw_cfg, but right now the answer > > is "there isn't one", and "register offsets are an arch specific > > detail". As such, the only reasonable way I saw was to copy the same > > values used in the QEMU source. > > > > See also: > > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05037.html > > > > Thanks much, > > --Gabriel > > My point is you don't know what will qemu do on these > other arches which do not at the moment have fw cfg. > So don't try to guess! Oh, you mean for the "else". I originally wanted to be able to compile this on any architecture and wanted some dummy defaults I could override on the command line. But now we're already restricting this to known architectures only, so I'll send a patch turning the warning into an error, and removing the #defines for the "else" branch above. Sorry I misunderstood you the first time around :) Thanks, --Gabriel
Re: [PATCH 3/6] perf, tools, stat: Support metrics in --per-core/socket mode
On Wed, Feb 17, 2016 at 02:44:02PM -0800, Andi Kleen wrote:
SNIP
> +static void aggr_update_shadow(void)
> +{
> + int cpu, cpu2, s2, id, s;
> + u64 val;
> + struct perf_evsel *counter;
> +
> + for (s = 0; s < aggr_map->nr; s++) {
> + id = aggr_map->map[s];
> + evlist__for_each(evsel_list, counter) {
> + val = 0;
> + for (cpu = 0; cpu < perf_evsel__nr_cpus(counter);
> cpu++) {
> + cpu2 = perf_evsel__cpus(counter)->map[cpu];
> + s2 = aggr_get_id(evsel_list->cpus, cpu2);
> + if (s2 != id)
> + continue;
> + val += perf_counts(counter->counts, cpu,
> 0)->val;
> + }
> + val = val * counter->scale;
> + perf_stat__update_shadow_stats(counter, &val,
> +
> first_shadow_cpu(counter, id));
> + }
> + }
> +}
> +
> static void print_aggr(char *prefix)
> {
> FILE *output = stat_config.output;
> @@ -982,6 +1024,8 @@ static void print_aggr(char *prefix)
> if (!(aggr_map || aggr_get_id))
> return;
>
> + aggr_update_shadow();
this should be called from perf_stat_process_counter,
not from display function
also please document somewhere (best around shadow stats variables)
what cpus (array members) are used for given AGGR_*
thanks,
jirka
[GIT PULL] irqchip: Core changes for v4.6 (second round)
Hey Thomas, Just wanted to get this PR in before the week hits. All changes have been included in -next at least on Thursday. This is an incremental PR from tags/irqchip-core-4.6 up to tags/irqchip-core-4.6-2 on the irqchip/core branch. Please pull. thx, Jason. The following changes since commit e4e1c0ea731e4a3df470110bfdf8a18d11d59351: irqchip/ts4800: Make ts4800_ic_ops static const (2016-02-18 02:09:18 +) are available in the git repository at: git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-4.6-2 for you to fetch changes up to 1ad9a57633e407f40a288ed1d8660fe06446a002: Merge branch 'irqchip/mvebu' into irqchip/core (2016-02-21 14:47:04 +) irqchip core changes for v4.6 (round 2) - mvebu: - Add odmi driver for Marvell 7K/8K SoCs - Replace driver-specific set_affinity with generic version - mips: - Move ath79 MISC and CPU drivers from arch/ code to irqchip/ - tango: - Add support for Sigma Designs SMP8[67]xx ctrl Alban Bedel (2): irqchip/ath79-misc: Move the MISC driver from arch/mips/ath79/ irqchip/ath79-cpu: Move the CPU IRQ driver from arch/mips/ath79/ Jason Cooper (3): Merge branch 'irqchip/tango' into irqchip/core Merge branch 'irqchip/mips' into irqchip/core Merge branch 'irqchip/mvebu' into irqchip/core Mans Rullgard (2): devicetree: Add binding for Sigma Designs SMP86xx interrupt controller irqchip/tango: Add support for Sigma Designs SMP86xx/SMP87xx interrupt controller Marc Zyngier (1): irqchip/gic: Return IRQ_SET_MASK_OK_DONE in the set_affinity method Thomas Petazzoni (1): irqchip/mvebu-odmi: Add new driver for platform MSI on Marvell 7K/8K .../marvell,odmi-controller.txt| 41 .../interrupt-controller/sigma,smp8642-intc.txt| 49 + arch/mips/ath79/irq.c | 244 ++--- arch/mips/include/asm/mach-ath79/ath79.h | 4 + drivers/irqchip/Kconfig| 9 + drivers/irqchip/Makefile | 4 + drivers/irqchip/irq-ath79-cpu.c| 97 drivers/irqchip/irq-ath79-misc.c | 189 drivers/irqchip/irq-gic-v2m.c | 14 +- drivers/irqchip/irq-gic.c | 2 +- drivers/irqchip/irq-mvebu-odmi.c | 236 drivers/irqchip/irq-tango.c| 232 12 files changed, 884 insertions(+), 237 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sigma,smp8642-intc.txt create mode 100644 drivers/irqchip/irq-ath79-cpu.c create mode 100644 drivers/irqchip/irq-ath79-misc.c create mode 100644 drivers/irqchip/irq-mvebu-odmi.c create mode 100644 drivers/irqchip/irq-tango.c
Re: [PATCH] rtc: Add an option to invalidate dates in 2038
> It doesn't change anything for 64-bit systems, I've excluded them by > using "depends on !64BIT". Right now, it doesn't change anything for > 32-bit systems because either way, they will fail in 2038. Which realistically won't actually matter because in 22 years time nobody will be able to find a 32bit system in common use. If you look at x86 platforms today a Pentium Pro is already a collectors item. All of todays locked down half-maintained embedded and phone devices will be at best the digital equivalent of toxic waste if connected to anything. > Won't we have to recompile every application to support 64-bit time on > 32-bit system anyway? That will be a good time to remove that option. How will you know when everyone has ? There's no "autodetect which distribution I am running" feature. > If the distribution don't recompile to support a 64-bit time, then the > 32-bit systems will break in 2038 anyway and they will absolutely > require my patch or something along those lines to still boot using > systemd. I disagree. Systemd has a serious robustness bug. Patch systemd to handle timerd going off early and to take appropriate recovery action. If you fix the systemd bug you'll also deal with a load of other weird cornercases like 32bit guests on a 64bit host that accidentally ended up post 2038, and every other freaky rtc failure. Alan
Re: [PATCH v2] power: bq27xxx_battery: Restore device name
On Saturday 06 February 2016 11:35:49 Pali Rohár wrote:
> On Tuesday 02 February 2016 13:47:37 Ivaylo Dimitrov wrote:
> > Patch <703df6c097956d17a818e63961c82e8e9eef9fef> ("power:
> > bq27xxx_battery: Reorganize I2C into a module") has removed the
> > device name numbering from bq27xxx_battery_i2c_probe. Fix that by
> > restoring the code.
> >
> > Signed-off-by: Ivaylo Dimitrov
>
> Fixes: 703df6c097956d17a818e63961c82e8e9eef9fef
> Reviewed-by: Pali Rohár
> Tested-by: Pali Rohár
>
> Please apply this patch and backport to stable kernels with already
> has patch 703df6c097956d17a818e63961c82e8e9eef9fef.
I still do not see this patch in any tree... Please apply.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Sun, Feb 21, 2016 at 10:30:26AM +0200, Michael S. Tsirkin wrote: > On Thu, Jan 28, 2016 at 09:23:11AM -0500, Gabriel L. Somlo wrote: > > From: Gabriel Somlo > > > > Make fw_cfg entries of type "file" available via sysfs. Entries > > are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders > > named after each entry's selector key. Filename, selector value, > > and size read-only attributes are included for each entry. Also, > > a "raw" attribute allows retrieval of the full binary content of > > each entry. > > > > The fw_cfg device can be instantiated automatically from ACPI or > > the Device Tree, or manually by using a kernel module (or command > > line) parameter, with a syntax outlined in the documentation file. > > > > Signed-off-by: Gabriel Somlo > > --- > > .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 58 ++ > > drivers/firmware/Kconfig | 19 + > > drivers/firmware/Makefile | 1 + > > drivers/firmware/qemu_fw_cfg.c | 648 > > + > > 4 files changed, 726 insertions(+) > > create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > > create mode 100644 drivers/firmware/qemu_fw_cfg.c > > > > diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > > b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > > new file mode 100644 > > index 000..e9e58d4 > > --- /dev/null > > +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > > @@ -0,0 +1,58 @@ > > +What: /sys/firmware/qemu_fw_cfg/ > > +Date: August 2015 > > +Contact: Gabriel Somlo > > +Description: > > + Several different architectures supported by QEMU (x86, arm, > > + sun4*, ppc/mac) are provisioned with a firmware configuration > > + (fw_cfg) device, originally intended as a way for the host to > > + provide configuration data to the guest firmware. Starting > > + with QEMU v2.4, arbitrary fw_cfg file entries may be specified > > + by the user on the command line, which makes fw_cfg additionally > > + useful as an out-of-band, asynchronous mechanism for providing > > + configuration data to the guest userspace. > > + > > + The authoritative guest-side hardware interface documentation > > + to the fw_cfg device can be found in "docs/specs/fw_cfg.txt" > > + in the QEMU source tree. > > + > > + === SysFS fw_cfg Interface === > > + > > + The fw_cfg sysfs interface described in this document is only > > + intended to display discoverable blobs (i.e., those registered > > + with the file directory), as there is no way to determine the > > + presence or size of "legacy" blobs (with selector keys between > > + 0x0002 and 0x0018) programmatically. > > + > > + All fw_cfg information is shown under: > > + > > + /sys/firmware/qemu_fw_cfg/ > > + > > + The only legacy blob displayed is the fw_cfg device revision: > > + > > + /sys/firmware/qemu_fw_cfg/rev > > + > > + --- Discoverable fw_cfg blobs by selector key --- > > + > > + All discoverable blobs listed in the fw_cfg file directory are > > + displayed as entries named after their unique selector key > > + value, e.g.: > > + > > + /sys/firmware/qemu_fw_cfg/by_key/32 > > + /sys/firmware/qemu_fw_cfg/by_key/33 > > + /sys/firmware/qemu_fw_cfg/by_key/34 > > + ... > > + > > + Each such fw_cfg sysfs entry has the following values exported > > + as attributes: > > + > > + name: The 56-byte nul-terminated ASCII string used as the > > + blob's 'file name' in the fw_cfg directory. > > + size: The length of the blob, as given in the fw_cfg > > + directory. > > + key : The value of the blob's selector key as given in the > > + fw_cfg directory. This value is the same as used in > > + the parent directory name. > > + raw : The raw bytes of the blob, obtained by selecting the > > + entry via the control register, and reading a number > > + of bytes equal to the blob size from the data > > + register. > > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > > index 49a3a11..5130f74 100644 > > --- a/drivers/firmware/Kconfig > > +++ b/drivers/firmware/Kconfig > > @@ -161,6 +161,25 @@ config RASPBERRYPI_FIRMWARE > > This option enables support for communicating with the firmware on the > > Raspberry Pi. > > > > +config FW_CFG_SYSFS > > + tristate "QEMU fw_cfg device support in sysfs" > > + depends on SYSFS && (ARM || ARM64 || PPC_PMAC || SPARC || X86) > > + default n >
Re: [PATCH v3 2/5] ACPI: parse SPCR and enable matching console
On Mon, Feb 15, 2016 at 09:05:26PM +0300, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
> Console Redirection Table) [2] as a mandatory ACPI table that
> specifies the configuration of serial console.
>
> Parse this table and check if any registered console match the
> description. If it does, enable that console.
>
> Introduce a new function acpi_console_check(). At the uart port
> registration, this function checks if the ACPI SPCR table specifies
> its argument of type struct uart_port to be a console
> and if so calls add_preferred_console().
>
> [1]
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0044a/index.html
> [2]
> http://msdn.microsoft.com/en-us/library/windows/hardware/dn639131(v=vs.85).aspx
>
> Signed-off-by: Aleksey Makarov
> ---
> drivers/acpi/Kconfig | 3 ++
> drivers/acpi/Makefile| 1 +
> drivers/acpi/spcr.c | 97
>
> drivers/tty/serial/serial_core.c | 14 +-
> include/linux/acpi.h | 10 +
> 5 files changed, 123 insertions(+), 2 deletions(-)
> create mode 100644 drivers/acpi/spcr.c
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 65fb483..5611eb6 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -77,6 +77,9 @@ config ACPI_DEBUGGER_USER
>
> endif
>
> +config ACPI_SPCR_TABLE
> + bool
> +
> config ACPI_SLEEP
> bool
> depends on SUSPEND || HIBERNATION
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 346101c..708b143 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -81,6 +81,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
> obj-$(CONFIG_ACPI_CUSTOM_METHOD)+= custom_method.o
> obj-$(CONFIG_ACPI_BGRT) += bgrt.o
> obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
> +obj-$(CONFIG_ACPI_SPCR_TABLE)+= spcr.o
> obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
>
> # processor has its own "processor." module_param namespace
> diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
> new file mode 100644
> index 000..a1eca91
> --- /dev/null
> +++ b/drivers/acpi/spcr.c
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2012, Intel Corporation
> + * Copyright (c) 2015, Red Hat, Inc.
> + * Copyright (c) 2015, 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#define pr_fmt(fmt) "ACPI: SPCR: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static int acpi_table_parse_spcr(int (*handler)(struct acpi_table_spcr
> *table,
> + void *data), void *data)
> +{
> + struct acpi_table_spcr *table = NULL;
Hi Alexey,
Few minor comments...
Are you sure you need thin initialization?
> + acpi_size table_size;
> + acpi_status status;
> + int err;
> +
> + status = acpi_get_table_with_size(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&table,
> + &table_size);
> +
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + err = handler(table, data);
> +
> + early_acpi_os_unmap_memory(table, table_size);
> +
> + return err;
> +}
> +
> +static int spcr_table_handler_check(struct acpi_table_spcr *table, void
> *data)
The name of function is not clear for me.
You're not only checking here, but also
adding console.
> +{
> + struct uart_port *uport = data;
> + char *options;
> +
> + if (table->header.revision < 2)
> + return -EOPNOTSUPP;
> +
> + switch (table->baud_rate) {
You don't need 'options' if your big condition returns false,
so you can evaluate it inside conditional block.
> + case 3:
> + options = "9600";
> + break;
> + case 4:
> + options = "19200";
> + break;
> + case 6:
> + options = "57600";
> + break;
> + case 7:
> + options = "115200";
> + break;
> + default:
> + options = "";
> + break;
'break' isnot needed here
> + }
> +
> + if ((table->serial_port.space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY &&
Nitpick: just for better readability, I'd split it onto a set of
separated checks:
foo() {
if (!cond1)
return 0;
if (!cond2)
return 0;
...
switch () {
case 1:
...
case 2:
...
case 3:
...
default:
...
}
return 1;
}
> + table->seri
[PATCH 1/5] perf tools: Fix assertion failure on dynamic entry
The dynamic entry is created for each field in a tracepoint event.
Since they have no fixed hpp format index, it should skip when
perf_hpp__reset_width() is called.
This caused following assertion failure..
$ perf record -e sched:sched_switch -a sleep 1
$ perf report -s comm,next_pid --stdio
perf: ui/hist.c:651: perf_hpp__reset_width:
Assertion `!(fmt->idx >= PERF_HPP__MAX_INDEX)' failed.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 1ba4117d9c2d..12223d791e9f 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -645,6 +645,9 @@ void perf_hpp__reset_width(struct perf_hpp_fmt *fmt, struct
hists *hists)
if (perf_hpp__is_sort_entry(fmt))
return perf_hpp__reset_sort_width(fmt, hists);
+ if (perf_hpp__is_dynamic_entry(fmt))
+ return;
+
BUG_ON(fmt->idx >= PERF_HPP__MAX_INDEX);
switch (fmt->idx) {
--
2.7.1
Re: [PATCH] jme: remove the jme driver as it is no longer maintained
On Sun, Feb 21, 2016 at 9:45 AM, One Thousand Gnomes wrote: >> I would appreciate some hint from someone who is more experienced with >> drivers. > > Start by testing > > - loading the driver as a module > - using the networking > - unloading the module (and checking it stays unloaded!) > > then suspend/resume > > If that works then you have a good starting point because you know a > sequence of actions that suspends properly. If it fails then it's going > to be rather more fun because it implies something in the hardware has > not been properly shut down. > > Alan Hi Alan, Thanks for your email, did you see my bug report? Because I tried all this already. The only workarounds I've found to work is one of these: $ rmmod jme # before suspend or $ ip link set ens34 down or $ echo 0 > /sys/power/pm_async # disable async power management Then resume works fine (I can't reproduce the hang). I'm not a C developer nor a kernel developer, I tried looking at the jme.c driver code but it's not clear what is broken and what needs fixing, so I would appreciate someone more experienced looking at the issue and giving me an idea or two. Thanks, Diego
Re: [PATCH 3/6] perf, tools, stat: Support metrics in --per-core/socket mode
On Wed, Feb 17, 2016 at 02:44:02PM -0800, Andi Kleen wrote:
SNIP
> @@ -892,7 +908,10 @@ static void printout(int id, int nr, struct perf_evsel
> *counter, double uval,
> struct perf_stat_output_ctx out;
> struct outstate os = {
> .fh = stat_config.output,
> - .prefix = prefix ? prefix : ""
> + .prefix = prefix ? prefix : "",
> + .id = id,
> + .nr = nr,
> + .evsel = counter,
> };
> print_metric_t pm = print_metric_std;
> void (*nl)(void *);
> @@ -962,15 +981,38 @@ static void printout(int id, int nr, struct perf_evsel
> *counter, double uval,
>
> perf_stat__print_shadow_stats(counter, uval,
> stat_config.aggr_mode == AGGR_GLOBAL ? 0 :
> - cpu_map__id_to_cpu(id),
> + first_shadow_cpu(counter, id),
hum, IIUC you need to handle AGGR_NONE in here as well?
thanks,
jirka
Re: [PATCH v5 3/4] media: pxa_camera: trivial move of dma irq functions
On Sun, 21 Feb 2016, Guennadi Liakhovetski wrote:
> Hi Robert,
>
> On Sun, 6 Sep 2015, Robert Jarzmik wrote:
>
> > This moves the dma irq handling functions up in the source file, so that
> > they are available before DMA preparation functions. It prepares the
> > conversion to DMA engine, where the descriptors are populated with these
> > functions as callbacks.
> >
> > Signed-off-by: Robert Jarzmik
> > ---
> > Since v1: fixed prototypes change
> > Since v4: refixed prototypes change
> > ---
> > drivers/media/platform/soc_camera/pxa_camera.c | 42
> > +++---
> > 1 file changed, 24 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
> > b/drivers/media/platform/soc_camera/pxa_camera.c
> > index db041a5ed444..bb7054221a86 100644
> > --- a/drivers/media/platform/soc_camera/pxa_camera.c
> > +++ b/drivers/media/platform/soc_camera/pxa_camera.c
> > @@ -311,6 +311,30 @@ static int calculate_dma_sglen(struct scatterlist
> > *sglist, int sglen,
> > return i + 1;
> > }
> >
> > +static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
> > + enum pxa_camera_active_dma act_dma);
>
> This is v5. You fixed prototypes in v1 and v4. Let's see:
>
> > +
> > +static void pxa_camera_dma_irq_y(int channel, void *data)
> > +{
> > + struct pxa_camera_dev *pcdev = data;
> > +
> > + pxa_camera_dma_irq(channel, pcdev, DMA_Y);
>
> This doesn't seem fixed to me.
Forget about this, I'll fix it locally.
>
> Thanks
> Guennadi
>
> > +}
> > +
> > +static void pxa_camera_dma_irq_u(int channel, void *data)
> > +{
> > + struct pxa_camera_dev *pcdev = data;
> > +
> > + pxa_camera_dma_irq(channel, pcdev, DMA_U);
> > +}
> > +
> > +static void pxa_camera_dma_irq_v(int channel, void *data)
> > +{
> > + struct pxa_camera_dev *pcdev = data;
> > +
> > + pxa_camera_dma_irq(channel, pcdev, DMA_V);
> > +}
> > +
> > /**
> > * pxa_init_dma_channel - init dma descriptors
> > * @pcdev: pxa camera device
> > @@ -802,24 +826,6 @@ out:
> > spin_unlock_irqrestore(&pcdev->lock, flags);
> > }
> >
> > -static void pxa_camera_dma_irq_y(int channel, void *data)
> > -{
> > - struct pxa_camera_dev *pcdev = data;
> > - pxa_camera_dma_irq(channel, pcdev, DMA_Y);
> > -}
> > -
> > -static void pxa_camera_dma_irq_u(int channel, void *data)
> > -{
> > - struct pxa_camera_dev *pcdev = data;
> > - pxa_camera_dma_irq(channel, pcdev, DMA_U);
> > -}
> > -
> > -static void pxa_camera_dma_irq_v(int channel, void *data)
> > -{
> > - struct pxa_camera_dev *pcdev = data;
> > - pxa_camera_dma_irq(channel, pcdev, DMA_V);
> > -}
> > -
> > static struct videobuf_queue_ops pxa_videobuf_ops = {
> > .buf_setup = pxa_videobuf_setup,
> > .buf_prepare= pxa_videobuf_prepare,
> > --
> > 2.1.4
> >
>
[PATCH v3] Fix sun7i pin assignment for IRQ's
After testing IRQ pins we found some bugs in the pinctrl declaration.
Signed-off-by: Henry Paulissen
---
Changes in v2:
After some more testing we found irq on PI pins.
they where on mux6 so this is included in my patch.
Also included is a warning for PI17, this pin was not working
on apritzel his bPI and he thinks it might be correlated to
GIC and IRQ 29.
Changes in v3:
Changed name from nickname to realname in email and SoB.
---
drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..0fe173e 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "nand0"), /* NCE4 */
SUNXI_FUNCTION(0x3, "spi2"), /* CS0 */
- SUNXI_FUNCTION_IRQ(0x6, 12)), /* EINT12 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "nand0"), /* NCE5 */
SUNXI_FUNCTION(0x3, "spi2"), /* CLK */
- SUNXI_FUNCTION_IRQ(0x6, 13)), /* EINT13 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "nand0"), /* NCE6 */
SUNXI_FUNCTION(0x3, "spi2"), /* MOSI */
- SUNXI_FUNCTION_IRQ(0x6, 14)), /* EINT14 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "nand0"), /* NCE7 */
SUNXI_FUNCTION(0x3, "spi2"), /* MISO */
- SUNXI_FUNCTION_IRQ(0x6, 15)), /* EINT15 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi0"), /* CS0 */
SUNXI_FUNCTION(0x3, "uart5"), /* TX */
- SUNXI_FUNCTION_IRQ(0x5, 22)), /* EINT22 */
+ SUNXI_FUNCTION_IRQ(0x6, 22)), /* EINT22 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi0"), /* CLK */
SUNXI_FUNCTION(0x3, "uart5"), /* RX */
- SUNXI_FUNCTION_IRQ(0x5, 23)), /* EINT23 */
+ SUNXI_FUNCTION_IRQ(0x6, 23)), /* EINT23 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi0"), /* MOSI */
SUNXI_FUNCTION(0x3, "uart6"), /* TX */
SUNXI_FUNCTION(0x4, "clk_out_a"), /* CLK_OUT_A */
- SUNXI_FUNCTION_IRQ(0x5, 24)), /* EINT24 */
+ SUNXI_FUNCTION_IRQ(0x6, 24)), /* EINT24 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi0"), /* MISO */
SUNXI_FUNCTION(0x3, "uart6"), /* RX */
SUNXI_FUNCTION(0x4, "clk_out_b"), /* CLK_OUT_B */
- SUNXI_FUNCTION_IRQ(0x5, 25)), /* EINT25 */
+ SUNXI_FUNCTION_IRQ(0x6, 25)), /* EINT25 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi0"), /* CS1 */
SUNXI_FUNCTION(0x3, "ps2"), /* SCK1 */
SUNXI_FUNCTION(0x4, "timer4"),/* TCLKIN0 */
- SUNXI_FUNCTION_IRQ(0x5, 26)), /* EINT26 */
+ SUNXI_FUNCTION_IRQ(0x6, 26)), /* EINT26 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
SUNXI_FUNCTION(0x0, "gpio_in"),
SUNXI_FUNCTION(0x1, "gpio_out"),
SUNXI_FUNCTION(0x2, "spi1"), /* CS1 */
SUNXI_FUNCTION(0x3, "ps2"), /* SDA1 */
SUNXI_FUNCTION(0x4, "timer5"),/* TCLKIN1 */
- SUNXI_FUNCTION_IRQ(0x5, 27
[PATCH] plusb added support for PL-27A1 , kernel 4.2.0-25
Hello all,
I made a patch to add support for Prolific PL-27A1 host-to-host USB 3.0
link cable. It's the same platform as PL-25A1 but with USB3.0 interface
so basically I only added right vendor/device id to get detected.
Maximum throughput I managed to get was about 1.5Gbps using iperf. I'll
investigate usbnet to get even higher throughput, if you have any tips
where to look, let me know.
Developed and tested under 4.2.0-25.
Best regards
Daniel Kucera.
diff --git a/drivers/net/usb/plusb.c b/drivers/net/usb/plusb.c
index 1bfe0fc..1239239 100644
--- a/drivers/net/usb/plusb.c
+++ b/drivers/net/usb/plusb.c
@@ -102,7 +102,7 @@ static int pl_reset(struct usbnet *dev)
}
static const struct driver_infoprolific_info = {
-.description ="Prolific PL-2301/PL-2302/PL-25A1",
+.description ="Prolific PL-2301/PL-2302/PL-25A1/PL-27A1",
.flags =FLAG_POINTTOPOINT | FLAG_NO_SETINT,
/* some PL-2302 versions seem to fail usb_set_interface() */
.reset =pl_reset,
@@ -139,6 +139,15 @@ static const struct usb_device_idproducts [] = {
* Host-to-Host Cable
*/
.driver_info = (unsigned long) &prolific_info,
+
+},
+
+/* super speed cables */
+{
+USB_DEVICE(0x067b, 0x27a1), /* goobay Active USB 3.0 Data Link
+ * Cable (PL-27A1)
+ */
+.driver_info = (unsigned long) &prolific_info,
},
{ },// END
@@ -158,5 +167,5 @@ static struct usb_driver plusb_driver = {
module_usb_driver(plusb_driver);
MODULE_AUTHOR("David Brownell");
-MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1 USB Host to Host Link
Driver");
+MODULE_DESCRIPTION("Prolific PL-2301/2302/25A1/27A1 USB Host to Host
Link Driver");
MODULE_LICENSE("GPL");
Re: [PATCH v3] Fix sun7i pin assignment for IRQ's
Hi,
On Sun, Feb 21, 2016 at 02:20:41PM +0100, Henry Paulissen wrote:
> After testing IRQ pins we found some bugs in the pinctrl declaration.
Your commit log is going to need some work. Which bugs? What tests did
you make? Why are you making these changes while the datasheet says
otherwise?
> Signed-off-by: Henry Paulissen
> ---
>
> Changes in v2:
> After some more testing we found irq on PI pins.
> they where on mux6 so this is included in my patch.
>
> Also included is a warning for PI17, this pin was not working
> on apritzel his bPI and he thinks it might be correlated to
> GIC and IRQ 29.
>
> Changes in v3:
> Changed name from nickname to realname in email and SoB.
> ---
> drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++--
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> index cf1ce0c..0fe173e 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
> @@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
> SUNXI_FUNCTION(0x1, "gpio_out"),
> SUNXI_FUNCTION(0x2, "nand0"), /* NCE4 */
> SUNXI_FUNCTION(0x3, "spi2"), /* CS0 */
> - SUNXI_FUNCTION_IRQ(0x6, 12)), /* EINT12 */
Have you tried to compile it?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH v3 6/6] kvm: arm64: Add ACPI support for virt arch timer
Hi Marc
On 9 February 2016 at 01:10, Marc Zyngier wrote:
> On 01/02/16 20:26, fu@linaro.org wrote:
>> From: Fu Wei
>>
>> This patch adds ACPI/GTDT support for virt arch timer
>> using the API in GTDT driver.
>>
>> Signed-off-by: Fu Wei
>> ---
>> virt/kvm/arm/arch_timer.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
>> index 0a279d3..4077347 100644
>> --- a/virt/kvm/arm/arch_timer.c
>> +++ b/virt/kvm/arm/arch_timer.c
>> @@ -385,6 +385,9 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>> {
>> struct device_node *np;
>> int ret = -EINVAL;
>> +#ifdef CONFIG_ACPI_GTDT
>> + struct arch_timer_data data;
>> +#endif
>>
>> np = of_find_matching_node(NULL, arch_timer_of_match);
>> if (!np) {
>> @@ -397,6 +400,11 @@ static int kvm_timer_get_ppi(unsigned int *ppi)
>> of_node_put(np);
>>
>> skip_of:
>> +#ifdef CONFIG_ACPI_GTDT
>> + if (!*ppi && !gtdt_arch_timer_data_init(NULL, &data))
>> + *ppi = data.virt_ppi;
>> +#endif
>> +
>> if (*ppi)
>> return 0;
>>
>>
>
> As I already pointed out in another thread hacking some KVM ACPI stuff,
> this is the wrong approach.
>
> We should have a *common* accessor in the timer code that exports the
> relevant information, whatever the firmware "du jour" is.
>
> See Julien's series, which seems to address the issue in a much more
> convincing way:
>
> https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018531.html
>
Thanks for your info, I have read through Julien's patchset in mailing list.
This patch is a improvement from Wei Huang's patch using my GTDT driver,
because his approach is getting info from DTB or ACPI directly.
But It seems Wei Huang is helping Julien on his patchset and trying to
provide Tested-by,
So I will delete these two patches(about kvm), and test Julien's patch also.
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Best regards,
Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
[RFC][PATCH v2 0/3] mm/zsmalloc: increase objects density and reduce memory wastage
Hello, RFC huge classes are evil. zsmalloc knows the watermark after which classes are considered to be ->huge - every object stored consumes the entire zspage (which consist of a single order-0 page). zram, however, has its own statically defined watermark for `bad' compression and stores every object larger than this watermark as a PAGE_SIZE, object, IOW, to a ->huge class, this results in increased memory consumption and memory wastage. And zram's 'bad' watermark is much lower than zsmalloc's one. Apart from that, 'bad' compressions are not so rare, on some of my tests 41% of writes are 'bad' compressions. This patch set inverts this 'huge class watermark' enforcement, it's zsmalloc that knows better, not zram. It also reduces the number of huge classes, this saves some memory. Since we request less pages for object larger than 3072 bytes, zmalloc in some cases should behave nicer when the system is getting low on free pages. Object's location is encoded as so mostly we have enough bits in OBJ_INDEX_BITS to increase ZS_MAX_ZSPAGE_ORDER and keep all of the classes. This is not true, however, on PAE/LPAE and PAGE_SHIFT 16 systems, so we need to preserve the exiting ZS_MAX_ZSPAGE_ORDER 2 limit there. Please commit 0003 for some numbers. Thanks to Joonsoo Kim for valuable questions and opinions. v2: -- keep ZS_MAX_PAGES_PER_ZSPAGE order of two (Joonsoo) -- suffice ZS_MIN_ALLOC_SIZE alignment requirement -- do not change ZS_MAX_PAGES_PER_ZSPAGE on PAE/LPAE and on PAGE_SHIFT 16 systems (Joonsoo) Sergey Senozhatsky (3): mm/zsmalloc: introduce zs_get_huge_class_size_watermark() zram: use zs_get_huge_class_size_watermark() mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE drivers/block/zram/zram_drv.c | 2 +- drivers/block/zram/zram_drv.h | 6 -- include/linux/zsmalloc.h | 2 ++ mm/zsmalloc.c | 43 --- 4 files changed, 39 insertions(+), 14 deletions(-) -- 2.7.1
Re: [PATCH 1/2] mmc-sdricoh_cs: Delete unnecessary variable initialisations in sdricoh_init_mmc()
Hello, Am Tue, 29 Dec 2015 22:00:35 +0100 schrieb SF Markus Elfring : > From: Markus Elfring > Date: Tue, 29 Dec 2015 21:11:45 +0100 > > These variables will eventually be set to an appropriate value a bit > later. > * host > * iobase > * result > > Thus let us omit the explicit initialisation at the beginning. > > Signed-off-by: Markus Elfring Acked-by: Sascha Sommer Best regards Sascha
Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Thu, Jan 28, 2016 at 09:23:11AM -0500, Gabriel L. Somlo wrote: > From: Gabriel Somlo > > Make fw_cfg entries of type "file" available via sysfs. Entries > are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders > named after each entry's selector key. Filename, selector value, > and size read-only attributes are included for each entry. Also, > a "raw" attribute allows retrieval of the full binary content of > each entry. > > The fw_cfg device can be instantiated automatically from ACPI or > the Device Tree, or manually by using a kernel module (or command > line) parameter, with a syntax outlined in the documentation file. > > Signed-off-by: Gabriel Somlo > --- > .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 58 ++ > drivers/firmware/Kconfig | 19 + > drivers/firmware/Makefile | 1 + > drivers/firmware/qemu_fw_cfg.c | 648 > + > 4 files changed, 726 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > create mode 100644 drivers/firmware/qemu_fw_cfg.c > > diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > new file mode 100644 > index 000..e9e58d4 > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg > @@ -0,0 +1,58 @@ > +What:/sys/firmware/qemu_fw_cfg/ > +Date:August 2015 > +Contact: Gabriel Somlo > +Description: > + Several different architectures supported by QEMU (x86, arm, > + sun4*, ppc/mac) are provisioned with a firmware configuration > + (fw_cfg) device, originally intended as a way for the host to > + provide configuration data to the guest firmware. Starting > + with QEMU v2.4, arbitrary fw_cfg file entries may be specified > + by the user on the command line, which makes fw_cfg additionally > + useful as an out-of-band, asynchronous mechanism for providing > + configuration data to the guest userspace. > + > + The authoritative guest-side hardware interface documentation > + to the fw_cfg device can be found in "docs/specs/fw_cfg.txt" > + in the QEMU source tree. > + > + === SysFS fw_cfg Interface === > + > + The fw_cfg sysfs interface described in this document is only > + intended to display discoverable blobs (i.e., those registered > + with the file directory), as there is no way to determine the > + presence or size of "legacy" blobs (with selector keys between > + 0x0002 and 0x0018) programmatically. > + > + All fw_cfg information is shown under: > + > + /sys/firmware/qemu_fw_cfg/ > + > + The only legacy blob displayed is the fw_cfg device revision: > + > + /sys/firmware/qemu_fw_cfg/rev > + > + --- Discoverable fw_cfg blobs by selector key --- > + > + All discoverable blobs listed in the fw_cfg file directory are > + displayed as entries named after their unique selector key > + value, e.g.: > + > + /sys/firmware/qemu_fw_cfg/by_key/32 > + /sys/firmware/qemu_fw_cfg/by_key/33 > + /sys/firmware/qemu_fw_cfg/by_key/34 > + ... > + > + Each such fw_cfg sysfs entry has the following values exported > + as attributes: > + > + name: The 56-byte nul-terminated ASCII string used as the > + blob's 'file name' in the fw_cfg directory. > + size: The length of the blob, as given in the fw_cfg > + directory. > + key : The value of the blob's selector key as given in the > + fw_cfg directory. This value is the same as used in > + the parent directory name. > + raw : The raw bytes of the blob, obtained by selecting the > + entry via the control register, and reading a number > + of bytes equal to the blob size from the data > + register. > diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig > index 49a3a11..5130f74 100644 > --- a/drivers/firmware/Kconfig > +++ b/drivers/firmware/Kconfig > @@ -161,6 +161,25 @@ config RASPBERRYPI_FIRMWARE > This option enables support for communicating with the firmware on the > Raspberry Pi. > > +config FW_CFG_SYSFS > + tristate "QEMU fw_cfg device support in sysfs" > + depends on SYSFS && (ARM || ARM64 || PPC_PMAC || SPARC || X86) > + default n > + help > + Say Y or M here to enable the exporting of the QEMU firmware > + configuration (fw_cfg) file entries via sysfs. Entries are > + found under
[PATCH] intel-hid: allocate correct amount of memory for private struct
We want the size of the struct, not of a pointer to it. To be future proof, just dereference the pointer to get the desired type. Signed-off-by: Wolfram Sang --- Compile tested only. Found by static code analysis. drivers/platform/x86/intel-hid.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-hid.c index e20f23e04c24ce..f93abc8c1424ad 100644 --- a/drivers/platform/x86/intel-hid.c +++ b/drivers/platform/x86/intel-hid.c @@ -180,8 +180,7 @@ static int intel_hid_probe(struct platform_device *device) return -ENODEV; } - priv = devm_kzalloc(&device->dev, - sizeof(struct intel_hid_priv *), GFP_KERNEL); + priv = devm_kzalloc(&device->dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; dev_set_drvdata(&device->dev, priv); -- 2.7.0
Re: [PATCH v5 1/4] media: pxa_camera: fix the buffer free path
On Sun, 21 Feb 2016, Robert Jarzmik wrote: > Guennadi Liakhovetski writes: > > >> Okay Guennadi, I retested this version on top of v4.5-rc2, still good to > >> go. There is a minor conflict in the includes since this submission, and I > >> can > >> repost a v6 which solves it. > > > > How did you test it with that patchg #3?? > I rebased my patches on top of v4.5-rc2. To be exact, I rebased the tree I had > with these last patches on top of v4.5-rc2. I'll recheck, it's been some time > ... > > > What's a minor conflict? > A conflict on a context line : > #include > #include > > I think linux/platform_data/media/camera-pxa.h changed from my last submssion, > hence the conflict. > > > If a patch doesn't apply at all or applies with a fuzz, yes, please fix. If > > it's just a few lines off, no need to fix that. But you'll do a v6 anyway, I > > assume. > But of course, let us have a v6 which cleanly applies on v4.5-rc2, and > restested > once more. I'll try to have it done this evening. Please, have a look at http://git.linuxtv.org/gliakhovetski/v4l-dvb.git/log/?h=for-4.6-2 If all is good there, no need for a v6 Thanks Guennadi > > Cheers. > > -- > Robert >
Re: [PATCH 2/2] mmc-sdricoh_cs: Less checks in sdricoh_init_mmc() after, error detection
Hello, Am Tue, 29 Dec 2015 22:02:37 +0100 schrieb SF Markus Elfring : > From: Markus Elfring > Date: Tue, 29 Dec 2015 21:45:34 +0100 > > This issue was detected by using the Coccinelle software. > > Two pointer checks could be repeated by the sdricoh_init_mmc() > function during error handling even if the relevant properties can be > determined for the involved variables before by source code analysis. > > * This implementation detail could be improved by adjustments > for jump targets according to the Linux coding style convention. > > * Drop an unnecessary initialisation for the variable "mmc" then. > > Signed-off-by: Markus Elfring > --- Acked-by: Sascha Sommer Best regards Sascha
Re: [PATCH] dmaengine: pl330: initialize tasklet after spin_unlock_irqrestore
Hi Krzysztof, On 19 February 2016 at 13:45, Lars-Peter Clausen wrote: > On 02/19/2016 09:10 AM, Anand Moon wrote: >> Hi Krzysztof, >> >> On 19 February 2016 at 12:50, Krzysztof Kozlowski >> wrote: >>> On 19.02.2016 15:39, Anand Moon wrote: Hi Krzysztof, On 19 February 2016 at 11:36, Krzysztof Kozlowski wrote: > 2016-02-19 2:21 GMT+09:00 Anand Moon : >> From: Anand Moon >> >> pl330_tasklet tasklet uses the same spinlock pch->lock for safe IRQ >> locking. >> It's safe to initialize pl330_tasklet tasklet after release of the >> locking. > > This is tasklet init, not tasklet execution (which you are referring > to in first sentence). I don't get how usage of spinlock during > execution guarantees the safeness during init... Please describe why > this is safe. > > Best regards, > Krzysztof > http://lxr.free-electrons.com/source/drivers/dma/pl330.c#L1972 pl330_tasklet function which is initiated by tasklet_init is trying to lock using same spin_unlock_irqsave/restore pch->lock. >>> >>> tasklet_init does not call pl330_tasklet (if this is what you mean by >>> "initiated"). What is the correlation? Why are you referring to the >>> locks in pl330_tasklet? >>> So better release the pch->lock and then initialize the tasklet_init. >>> >>> Why "better"? >>> >>> Best regards, >>> Krzysztof >>> >> >> On SMP arch, tasklet_init could spawn the pl330_tasklet routine, >> it could be any CPU which could take up this task. >> So just for good timing of Initialization of the pl330_tasklet after >> spin_unlock_irqrestore. >> That is what I can figure out. > > Hi, > > tasklet_init() does not spwan the tasklet function, tasklet_schedule() does > that. > > But there is still room for optimization here. If you want to move the > tasklet_init() call please move it into pl330_probe() next to where the > channel is allocated. There is no need to re-initialize the tasklet each > time the channel is requested. > > - Lars > After looking at the history of the change logs. I found below changes. commit da331ba8e9c5de72a27e50f71105395bba6eebe0 Author: Bartlomiej Zolnierkiewicz Date: Wed Jul 3 15:00:43 2013 -0700 drivers/dma/pl330.c: fix locking in pl330_free_chan_resources() tasklet_kill() may sleep so call it before taking pch->lock. - sorry for the noise. Next time I will be more careful. -Anand Moon
Re: [PATCH 2/5] perf tools: Fix segfault on dynamic entries
On Sun, Feb 21, 2016 at 11:22:35PM +0900, Namhyung Kim wrote:
> The dynamic entry is created for each tracepoint event. When it sets up
> the sort key, it checks with existing keys using ->equal() callback.
> But it missed to set the ->equal for dynamic entries. The following
> segfault was due to the missing ->equal() callback.
>
> (gdb) bt
> #0 0x00140003 in ?? ()
> #1 0x00537769 in fmt_equal (b=0x2106980, a=0x21067a0) at
> ui/hist.c:548
> #2 perf_hpp__setup_output_field (list=0x8c6d80 ) at
> ui/hist.c:560
> #3 0x004e927e in setup_sorting (evlist=) at
> util/sort.c:2642
> #4 0x0043cf50 in cmd_report (argc=, argv= out>, prefix=)
> at builtin-report.c:932
> #5 0x004865a1 in run_builtin (p=p@entry=0x8bbce0 ,
> argc=argc@entry=7,
> argv=argv@entry=0x7ffd24d56ce0) at perf.c:390
> #6 0x0042dc1f in handle_internal_command (argv=0x7ffd24d56ce0,
> argc=7) at perf.c:451
> #7 run_argv (argv=0x7ffd24d56a70, argcp=0x7ffd24d56a7c) at perf.c:495
> #8 main (argc=7, argv=0x7ffd24d56ce0) at perf.c:620
>
> Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/util/sort.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index de715756f281..7daea71691df 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -1835,6 +1835,20 @@ bool perf_hpp__is_dynamic_entry(struct perf_hpp_fmt
> *fmt)
> return fmt->cmp == __sort__hde_cmp;
> }
>
> +static bool __sort__hde_equal(struct perf_hpp_fmt *a, struct perf_hpp_fmt *b)
> +{
> + struct hpp_dynamic_entry *hde_a;
> + struct hpp_dynamic_entry *hde_b;
> +
> + if (!perf_hpp__is_dynamic_entry(a) || !perf_hpp__is_dynamic_entry(b))
> + return false;
> +
> + hde_a = container_of(a, struct hpp_dynamic_entry, hpp);
> + hde_b = container_of(b, struct hpp_dynamic_entry, hpp);
> +
> + return hde_a->field == hde_b->field;
> +}
> +
> static void hde_free(struct perf_hpp_fmt *fmt)
> {
> struct hpp_dynamic_entry *hde;
> @@ -1867,6 +1881,7 @@ __alloc_dynamic_entry(struct perf_evsel *evsel, struct
> format_field *field)
> hde->hpp.cmp = __sort__hde_cmp;
> hde->hpp.collapse = __sort__hde_cmp;
> hde->hpp.sort = __sort__hde_cmp;
> + hde->hpp.equal = __sort__hde_equal;
> hde->hpp.free = hde_free;
>
> INIT_LIST_HEAD(&hde->hpp.list);
> --
> 2.7.1
>
Re: [PATCH 1/5] perf tools: Fix assertion failure on dynamic entry
On Sun, Feb 21, 2016 at 11:22:34PM +0900, Namhyung Kim wrote:
> The dynamic entry is created for each field in a tracepoint event.
> Since they have no fixed hpp format index, it should skip when
> perf_hpp__reset_width() is called.
>
> This caused following assertion failure..
>
> $ perf record -e sched:sched_switch -a sleep 1
>
> $ perf report -s comm,next_pid --stdio
> perf: ui/hist.c:651: perf_hpp__reset_width:
> Assertion `!(fmt->idx >= PERF_HPP__MAX_INDEX)' failed.
>
> Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/ui/hist.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
> index 1ba4117d9c2d..12223d791e9f 100644
> --- a/tools/perf/ui/hist.c
> +++ b/tools/perf/ui/hist.c
> @@ -645,6 +645,9 @@ void perf_hpp__reset_width(struct perf_hpp_fmt *fmt,
> struct hists *hists)
> if (perf_hpp__is_sort_entry(fmt))
> return perf_hpp__reset_sort_width(fmt, hists);
>
> + if (perf_hpp__is_dynamic_entry(fmt))
> + return;
> +
> BUG_ON(fmt->idx >= PERF_HPP__MAX_INDEX);
>
> switch (fmt->idx) {
> --
> 2.7.1
>
Re: [PATCH 3/5] perf tools: Update srcline/file if needed
On Sun, Feb 21, 2016 at 11:22:36PM +0900, Namhyung Kim wrote:
> Normally the hist entry's srcline and/or srcfile is set during sorting.
> However sometime it's possible to a hist entry's srcline is not set yet
> after the sorting. This is because the entry is so unique and other
> sort keys already make it distinct. Then the srcline/file sort didn't
> have a chance to be called during the sorting. In that case it has NULL
> srcline/srcfile field and shows nothing.
>
> Before:
>
> $ perf report -s comm,sym,srcline
> ...
> Overhead Command Symbol
> -
> 34.42% swapper [k] intel_idle intel_idle.c:0
> 2.44% perf [.] __poll_nocancel (null)
> 1.70% gnome-shell [k] fw_domains_get (null)
> 1.04% Xorg [k] sock_poll (null)
>
> After:
>
> 34.42% swapper [k] intel_idle intel_idle.c:0
> 2.44% perf [.] __poll_nocancel .:0
> 1.70% gnome-shell [k] fw_domains_get fw_domains_get+42
> 1.04% Xorg [k] sock_poll socket.c:0
>
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/sort.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 7daea71691df..6808d73164b5 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -315,6 +315,16 @@ sort__srcline_cmp(struct hist_entry *left, struct
> hist_entry *right)
> static int hist_entry__srcline_snprintf(struct hist_entry *he, char *bf,
> size_t size, unsigned int width)
> {
> + if (!he->srcline) {
> + if (!he->ms.map)
> + he->srcline = SRCLINE_UNKNOWN;
> + else {
> + struct map *map = he->ms.map;
> + he->srcline = get_srcline(map->dso,
> +map__rip_2objdump(map, he->ip),
> + he->ms.sym, true);
> + }
> + }
could you put this into the function and use it
also within sort__srcline_cmp?
it's already 3 places duplicating the same code
thanks,
jirka
Re: [PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults
On 21.02.2016 12:25, Vasily Averin wrote:
Konstantin,
I've investigated question with sysctls initialization inside namespaces some
time ago.
IIRC I've found people expect that sysctl values should be inherited from
parent namespace.
It allows node admin to adjust unsafe pre-compiled settings, and prepare
adequate defaults
before creation of namespaces.
Only few sysctls are handled in this manner and they are copied from host,
not parent. This works somehow for flat containers, as soon as you go deeper
this turns into madness. Default settings must be controlled by software who
creates namespaces. For now it must reset all yet-not-known sysctls into sane
defaults.
BTW two ipv6 sysctl are special: net.ipv6.conf.default.disable_ipv6 and
net.ipv6.conf.default.autoconf their defaults are controlled by module
parameters and inherited by all namespaces. And this makes sense.
However, there is corner case:
module with sysctl can be loaded after creation of namespaces.
In this case namespaces will get pre-compiled sysctl defaults,
and are not be able to adjust them even if they want to do it.
Thank you,
Vasily Averin
On 21.02.2016 10:11, Konstantin Khlebnikov wrote:
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are
copied from init network namespace because static structures are used
for init_net. This makes no sense because new netns might be created
from any netns. This patch makes private copy also for init netns if
network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6
already initialized with default values at namespace creation.
Signed-off-by: Konstantin Khlebnikov
Fixes: 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")
---
net/ipv4/devinet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index cebd9d31e65a..9d73d4bbdba3 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net)
all = &ipv4_devconf;
dflt = &ipv4_devconf_dflt;
- if (!net_eq(net, &init_net)) {
+ if (IS_ENABLED(CONFIG_NET_NS)) {
all = kmemdup(all, sizeof(ipv4_devconf), GFP_KERNEL);
if (!all)
goto err_alloc_all;
--
Konstantin
Re: [PATCH 4/5] perf tools: Fix alignment on some sort keys
On Sun, Feb 21, 2016 at 11:22:37PM +0900, Namhyung Kim wrote:
> The srcline, srcfile and trace sort keys can have long entries. With
> commit 89fee7094323 ("perf hists: Do column alignment on the format
> iterator"), it now aligns output with hist_entry__snprintf_alignment().
> So each (possibly long) sort entries don't need to do it themselves.
Acked-by: Jiri Olsa
thanks,
jirka
>
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/sort.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
> index 6808d73164b5..1d2b85c808d0 100644
> --- a/tools/perf/util/sort.c
> +++ b/tools/perf/util/sort.c
> @@ -325,7 +325,7 @@ static int hist_entry__srcline_snprintf(struct hist_entry
> *he, char *bf,
> he->ms.sym, true);
> }
> }
> - return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcline);
> + return repsep_snprintf(bf, size, "%-.*s", width, he->srcline);
> }
>
> struct sort_entry sort_srcline = {
> @@ -384,7 +384,7 @@ static int hist_entry__srcfile_snprintf(struct hist_entry
> *he, char *bf,
> else
> he->srcfile = get_srcfile(he);
> }
> - return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcfile);
> + return repsep_snprintf(bf, size, "%-.*s", width, he->srcfile);
> }
>
> struct sort_entry sort_srcfile = {
> @@ -514,11 +514,11 @@ static int hist_entry__trace_snprintf(struct hist_entry
> *he, char *bf,
>
> evsel = hists_to_evsel(he->hists);
> if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
> - return scnprintf(bf, size, "%-*.*s", width, width, "N/A");
> + return scnprintf(bf, size, "%-.*s", width, "N/A");
>
> if (he->trace_output == NULL)
> he->trace_output = get_trace_output(he);
> - return repsep_snprintf(bf, size, "%-*.*s", width, width,
> he->trace_output);
> + return repsep_snprintf(bf, size, "%-.*s", width, he->trace_output);
> }
>
> struct sort_entry sort_trace = {
> --
> 2.7.1
>
Re: [PATCH 5/5] perf tools: Fix column width setting on 'trace' sort key
On Sun, Feb 21, 2016 at 11:22:38PM +0900, Namhyung Kim wrote: > It missed to update column length of the 'trace' sort key in the > hists__calc_col_len() so it might truncate the output. It calculated > the column length in the ->cmp() callback originally but it doesn't > guarantee it's called always. Acked-by: Jiri Olsa thanks, jirka > > Signed-off-by: Namhyung Kim > --- > tools/perf/util/hist.c | 3 +++ > tools/perf/util/sort.c | 3 --- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c > index 827c6cbcd05d..017eb5c42c37 100644 > --- a/tools/perf/util/hist.c > +++ b/tools/perf/util/hist.c > @@ -179,6 +179,9 @@ void hists__calc_col_len(struct hists *hists, struct > hist_entry *h) > if (h->transaction) > hists__new_col_len(hists, HISTC_TRANSACTION, > hist_entry__transaction_len()); > + > + if (h->trace_output) > + hists__new_col_len(hists, HISTC_TRACE, strlen(h->trace_output)); > } > > void hists__output_recalc_col_len(struct hists *hists, int max_rows) > diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c > index 1d2b85c808d0..ea05497cfee9 100644 > --- a/tools/perf/util/sort.c > +++ b/tools/perf/util/sort.c > @@ -501,9 +501,6 @@ sort__trace_cmp(struct hist_entry *left, struct > hist_entry *right) > if (right->trace_output == NULL) > right->trace_output = get_trace_output(right); > > - hists__new_col_len(left->hists, HISTC_TRACE, > strlen(left->trace_output)); > - hists__new_col_len(right->hists, HISTC_TRACE, > strlen(right->trace_output)); > - > return strcmp(right->trace_output, left->trace_output); > } > > -- > 2.7.1 >
Re: Camel Case
On 2/20/16, Jeff Merkey wrote: > Is camel case discouraged in linux code? I noticed a check for it in > checkpatch.pl but it is not one of the default options form scanning. > > Jeff > Found a great writeup from Greg on the subject. question answered. Do not use it if possible. Cool that checkpatch fixes camel case. Jeff
Re: [PATCH v2] Fix sun7i pin assignment for IRQ's
On Sun, Feb 21, 2016 at 9:54 AM, hp197 wrote: > After testing IRQ pins we found some bugs in the pinctrl declaration. > > Signed-off-by: hp197 Please resend with your full name on the commit and the SoB. The patch itself looks good. ChenYu
Re: [PATCH] PM: declare __tracedata symbols as char[] rather than char
On Sunday, January 24, 2016 08:08:52 PM Eric Biggers wrote: > Accessing more than one byte from a symbol declared simply 'char' is undefined > behavior, as reported by UBSAN: > > UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18 > load of address 8203fc78 with insufficient space > for an object of type 'char' > > Avoid this by declaring the symbols as arrays. > > Signed-off-by: Eric Biggers Queued up for 4.6, thanks! Rafael
Re: [PATCH 6/6] ARM: dts: n900: Rename isp1704 to isp1707 to match correct name
On Sun 2016-02-21 12:28:23, Pali Rohár wrote: > This change does not break existing userspace or Maemo software because > isp1704_charger.c always export power supply device under isp1704 name. ..exports.. > Signed-off-by: Pali Rohár 4,5,6: Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCHv6 1/3] rdmacg: Added rdma cgroup controller
On Sun, Feb 21, 2016 at 07:41:08PM +0530, Parav Pandit wrote: > CONFIG_CGROUP_RDMA > > On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote: > > On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote: > >> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote: > >> > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote: > >> > Can you place this ifdef before declaring struct rdma_cgroup? > >> Yes. I missed out this cleanup. Done locally now. > > > > Great, additional thing which spotted my attention was related to > > declaring and using the new cgroups functions. There are number of > > places where you protected the calls by specific ifdefs in the > > IB/core c-files and not in h-files as it is usually done. > > > ib_device_register_rdmacg, ib_device_unregister_rdmacg are the only > two functions called from IB/core as its tied to functionality. > They can also be implemented as NULL call when CONFIG_CGROUP_RDMA is > undefined. > (Similar to ib_rdmacg_try_charge and others). > I didn't do because occurrence of call of register and unregister is > limited to single file and only twice compare to charge/uncharge > functions. > Either way is fine with me, I can make the changes which you > described. Let me know. Please do, IMHO, it is better to have one place which handles all relevant ifdefs and functions. IB/core doesn't need to know about cgroups implementation. Thanks
[PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults
Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are
copied from init network namespace because static structures are used
for init_net. This makes no sense because new netns might be created
from any netns. This patch makes private copy also for init netns if
network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6
already initialized with default values at namespace creation.
Signed-off-by: Konstantin Khlebnikov
Fixes: 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")
---
net/ipv4/devinet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index cebd9d31e65a..9d73d4bbdba3 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net)
all = &ipv4_devconf;
dflt = &ipv4_devconf_dflt;
- if (!net_eq(net, &init_net)) {
+ if (IS_ENABLED(CONFIG_NET_NS)) {
all = kmemdup(all, sizeof(ipv4_devconf), GFP_KERNEL);
if (!all)
goto err_alloc_all;
Re: [PATCH] ipv4: in new netns initialize sysctls in net.ipv4.conf.* with defaults
Konstantin,
I've investigated question with sysctls initialization inside namespaces some
time ago.
IIRC I've found people expect that sysctl values should be inherited from
parent namespace.
It allows node admin to adjust unsafe pre-compiled settings, and prepare
adequate defaults
before creation of namespaces.
However, there is corner case:
module with sysctl can be loaded after creation of namespaces.
In this case namespaces will get pre-compiled sysctl defaults,
and are not be able to adjust them even if they want to do it.
Thank you,
Vasily Averin
On 21.02.2016 10:11, Konstantin Khlebnikov wrote:
> Currently initial net.ipv4.conf.all.* and net.ipv4.conf.default.* are
> copied from init network namespace because static structures are used
> for init_net. This makes no sense because new netns might be created
> from any netns. This patch makes private copy also for init netns if
> network namespaces are enabled. Other sysctls in net.ipv4 and net.ipv6
> already initialized with default values at namespace creation.
>
> Signed-off-by: Konstantin Khlebnikov
> Fixes: 752d14dc6aa9 ("[IPV4]: Move the devinet pointers on the struct net")
> ---
> net/ipv4/devinet.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
> index cebd9d31e65a..9d73d4bbdba3 100644
> --- a/net/ipv4/devinet.c
> +++ b/net/ipv4/devinet.c
> @@ -2290,7 +2290,7 @@ static __net_init int devinet_init_net(struct net *net)
> all = &ipv4_devconf;
> dflt = &ipv4_devconf_dflt;
>
> - if (!net_eq(net, &init_net)) {
> + if (IS_ENABLED(CONFIG_NET_NS)) {
> all = kmemdup(all, sizeof(ipv4_devconf), GFP_KERNEL);
> if (!all)
> goto err_alloc_all;
>
>
Re: [PATCH] ARM: dts: n900: Use linux input defines instead hardcoded constants
Hi,
On Sun, Feb 21, 2016 at 12:06:48PM +0100, Pali Rohár wrote:
> This makes DTS structure more readable.
>
> Signed-off-by: Pali Rohár
> ---
> arch/arm/boot/dts/omap3-n900.dts | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts
> b/arch/arm/boot/dts/omap3-n900.dts
> index e0443cd..85c29f3 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -65,45 +65,45 @@
> camera_lens_cover {
> label = "Camera Lens Cover";
> gpios = <&gpio4 14 GPIO_ACTIVE_LOW>; /* 110 */
> - linux,input-type = <5>; /* EV_SW */
> - linux,code = <0x09>; /* SW_CAMERA_LENS_COVER */
> + linux,input-type = ;
> + linux,code = ;
> wakeup-source;
> };
>
> camera_focus {
> label = "Camera Focus";
> gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; /* 68 */
> - linux,code = <0x210>; /* KEY_CAMERA_FOCUS */
> + linux,code = ;
> wakeup-source;
> };
>
> camera_capture {
> label = "Camera Capture";
> gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; /* 69 */
> - linux,code = <0xd4>; /* KEY_CAMERA */
> + linux,code = ;
> wakeup-source;
> };
>
> lock_button {
> label = "Lock Button";
> gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; /* 113 */
> - linux,code = <0x98>; /* KEY_SCREENLOCK */
> + linux,code = ;
> wakeup-source;
> };
>
> keypad_slide {
> label = "Keypad Slide";
> gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */
> - linux,input-type = <5>; /* EV_SW */
> - linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */
> + linux,input-type = ;
> + linux,code = ;
> wakeup-source;
> };
>
> proximity_sensor {
> label = "Proximity Sensor";
> gpios = <&gpio3 25 GPIO_ACTIVE_HIGH>; /* 89 */
> - linux,input-type = <5>; /* EV_SW */
> - linux,code = <0x0b>; /* SW_FRONT_PROXIMITY */
> + linux,input-type = ;
> + linux,code = ;
> };
> };
>
Acked-By: Sebastian Reichel
-- Sebastian
signature.asc
Description: PGP signature
[RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark()
From: Sergey Senozhatsky
zram should stop enforcing its own 'bad' object size watermark,
and start using zs_get_huge_class_size_watermark(). zsmalloc
really knows better.
Drop `max_zpage_size' and use zs_get_huge_class_size_watermark()
instead.
Signed-off-by: Sergey Senozhatsky
---
drivers/block/zram/zram_drv.c | 2 +-
drivers/block/zram/zram_drv.h | 6 --
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 46055db..2621564 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -714,7 +714,7 @@ static int zram_bvec_write(struct zram *zram, struct
bio_vec *bvec, u32 index,
goto out;
}
src = zstrm->buffer;
- if (unlikely(clen > max_zpage_size)) {
+ if (unlikely(clen > zs_get_huge_class_size_watermark())) {
clen = PAGE_SIZE;
if (is_partial_io(bvec))
src = uncmem;
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 8e92339..8879161 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -23,12 +23,6 @@
/*-- Configurable parameters */
/*
- * Pages that compress to size greater than this are stored
- * uncompressed in memory.
- */
-static const size_t max_zpage_size = PAGE_SIZE / 4 * 3;
-
-/*
* NOTE: max_zpage_size must be less than or equal to:
* ZS_MAX_ALLOC_SIZE. Otherwise, zs_malloc() would
* always return failure.
--
2.7.1
Re: [PATCH] ARM: dts: omap3-n900: Allow gpio keys to be disabled
On 12.02.2016 23:53, Tony Lindgren wrote: Looks like this no longer applies because of linux,can-disable to wakeup-source changes. Can you please update against v4.5-rc series and repost? Could you elaborate on that? As I don't really understand what needs to be updated and what are "wakeup-source changes". Thanks, Ivo
Re: [PATCH v6 10/25] perf hists: Resort hist entries with hierarchy
On Sun, Feb 21, 2016 at 12:19:18AM +0100, Jiri Olsa wrote:
> On Tue, Feb 16, 2016 at 11:08:28PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > @@ -1349,6 +1427,17 @@ static void output_resort(struct hists *hists,
> > struct ui_progress *prog,
> >
> > min_callchain_hits = callchain_total * (callchain_param.min_percent /
> > 100);
> >
> > + hists__reset_stats(hists);
> > + hists__reset_col_len(hists);
> > +
> > + if (symbol_conf.report_hierarchy) {
> > + return hists__hierarchy_output_resort(hists, prog,
> > + &hists->entries_collapsed,
> > + &hists->entries,
> > + min_callchain_hits,
> > + use_callchain);
> > + }
> > +
> > if (sort__need_collapse)
> > root = &hists->entries_collapsed;
> > else
> > @@ -1357,9 +1446,6 @@ static void output_resort(struct hists *hists, struct
> > ui_progress *prog,
> > next = rb_first(root);
> > hists->entries = RB_ROOT;
>
> above line could be moved together with those 2 below
> and you can then remove *root_out = RB_ROOT; line in
> hists__hierarchy_output_resort
Nope. The root_out should be initialized anyway since it's called
recursively with child's hroot_out.
Thanks,
Namhyung
> >
> > - hists__reset_stats(hists);
> > - hists__reset_col_len(hists);
> > -
> > while (next) {
> > n = rb_entry(next, struct hist_entry, rb_node_in);
> > next = rb_next(&n->rb_node_in);
> > --
> > 2.7.1
> >
Re: [PATCH 4/7] atmel-isi: fix IS_ERR_VALUE usage
Hi Andrzej,
On Mon, 15 Feb 2016, Andrzej Hajda wrote:
> IS_ERR_VALUE macro should be used only with unsigned long type.
> For signed types comparison 'ret < 0' should be used.
>
> The patch follows conclusion from discussion on LKML [1][2].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2120927
> [2]: http://permalink.gmane.org/gmane.linux.kernel/2150581
>
> Signed-off-by: Andrzej Hajda
Thanks for the patch, but this one
https://lkml.org/lkml/2016/2/9/392
came a couple of days earlier. Unless there is an important reason to use
yours, I'll use that one.
Thanks
Guennadi
> ---
> drivers/media/platform/soc_camera/atmel-isi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
> b/drivers/media/platform/soc_camera/atmel-isi.c
> index 1af779e..ab2d9b9 100644
> --- a/drivers/media/platform/soc_camera/atmel-isi.c
> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
> @@ -1026,7 +1026,7 @@ static int atmel_isi_parse_dt(struct atmel_isi *isi,
>
> static int atmel_isi_probe(struct platform_device *pdev)
> {
> - unsigned int irq;
> + int irq;
> struct atmel_isi *isi;
> struct resource *regs;
> int ret, i;
> @@ -1086,7 +1086,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
> isi->width_flags |= 1 << 9;
>
> irq = platform_get_irq(pdev, 0);
> - if (IS_ERR_VALUE(irq)) {
> + if (irq < 0) {
> ret = irq;
> goto err_req_irq;
> }
> --
> 1.9.1
>
Re: [PATCHv6 1/3] rdmacg: Added rdma cgroup controller
On Sun, Feb 21, 2016 at 8:39 PM, Leon Romanovsky wrote: > On Sun, Feb 21, 2016 at 07:41:08PM +0530, Parav Pandit wrote: >> CONFIG_CGROUP_RDMA >> >> On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote: >> > On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote: >> >> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote: >> >> > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote: >> >> > Can you place this ifdef before declaring struct rdma_cgroup? >> >> Yes. I missed out this cleanup. Done locally now. >> > >> > Great, additional thing which spotted my attention was related to >> > declaring and using the new cgroups functions. There are number of >> > places where you protected the calls by specific ifdefs in the >> > IB/core c-files and not in h-files as it is usually done. >> > >> ib_device_register_rdmacg, ib_device_unregister_rdmacg are the only >> two functions called from IB/core as its tied to functionality. >> They can also be implemented as NULL call when CONFIG_CGROUP_RDMA is >> undefined. >> (Similar to ib_rdmacg_try_charge and others). >> I didn't do because occurrence of call of register and unregister is >> limited to single file and only twice compare to charge/uncharge >> functions. >> Either way is fine with me, I can make the changes which you >> described. Let me know. > > Please do, > IMHO, it is better to have one place which handles all relevant ifdefs > and functions. IB/core doesn't need to know about cgroups implementation. > ok. Done. Thanks for the review. I will accumulate more comments from Tejun and others before spinning v7.
[PULL] NBD for 4.6
Hi Jens, This pull request contains 7 patches for 4.6. Patch 1 fixes some unnecessarily complicated code I introduced some versions ago for debugfs. Patch 2 removes the criticised signal usage within NBD to kill the NBD threads after a timeout. This code was used for the last years and is now replaced by simply killing the tcp connection. Patches 3-6 are some smaller cleanups. Patch 7 uevents for the userspace. This way udev/systemd can react on connected NBD devices. Best Regards, Markus The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.pengutronix.de/git/mpa/linux-nbd.git tags/nbd-for-4.6 for you to fetch changes up to 37091fdd831f28a6509008542174ed324dd645bc: nbd: Create size change events for userspace (2016-02-15 10:35:47 +0100) NBD for 4.6 Dan Streetman (1): nbd: ratelimit error msgs after socket close Markus Pargmann (6): nbd: Fix debugfs error handling nbd: Remove signal usage nbd: Timeouts are not user requested disconnects nbd: Cleanup reset of nbd and bdev after a disconnect nbd: Move flag parsing to a function nbd: Create size change events for userspace drivers/block/nbd.c | 335 ++-- 1 file changed, 170 insertions(+), 165 deletions(-) -- 2.7.0
[PATCH 4/7] nbd: Cleanup reset of nbd and bdev after a disconnect
Group all variables that are reset after a disconnect into reset
functions. This patch adds two of these functions, nbd_reset() and
nbd_bdev_reset().
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 2e14e51b5ea3..34a46c32c24f 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -617,6 +617,30 @@ out:
return ret;
}
+/* Reset all properties of an NBD device */
+static void nbd_reset(struct nbd_device *nbd)
+{
+ nbd->disconnect = false;
+ nbd->timedout = false;
+ nbd->blksize = 1024;
+ nbd->bytesize = 0;
+ set_capacity(nbd->disk, 0);
+ nbd->flags = 0;
+ nbd->xmit_timeout = 0;
+ queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
+ del_timer_sync(&nbd->timeout_timer);
+}
+
+static void nbd_bdev_reset(struct block_device *bdev)
+{
+ set_device_ro(bdev, false);
+ bdev->bd_inode->i_size = 0;
+ if (max_part > 0) {
+ blkdev_reread_part(bdev);
+ bdev->bd_invalidated = 1;
+ }
+}
+
static int nbd_dev_dbg_init(struct nbd_device *nbd);
static void nbd_dev_dbg_close(struct nbd_device *nbd);
@@ -745,19 +769,15 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
sock_shutdown(nbd);
nbd_clear_que(nbd);
kill_bdev(bdev);
- queue_flag_clear_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
- set_device_ro(bdev, false);
- nbd->flags = 0;
- nbd->bytesize = 0;
- bdev->bd_inode->i_size = 0;
- set_capacity(nbd->disk, 0);
- if (max_part > 0)
- blkdev_reread_part(bdev);
+ nbd_bdev_reset(bdev);
+
if (nbd->disconnect) /* user requested, ignore socket errors */
error = 0;
if (nbd->timedout)
error = -ETIMEDOUT;
+ nbd_reset(nbd);
+
return error;
}
@@ -1023,14 +1043,12 @@ static int __init nbd_init(void)
nbd_dev[i].timeout_timer.data = (unsigned long)&nbd_dev[i];
init_waitqueue_head(&nbd_dev[i].active_wq);
init_waitqueue_head(&nbd_dev[i].waiting_wq);
- nbd_dev[i].blksize = 1024;
- nbd_dev[i].bytesize = 0;
disk->major = NBD_MAJOR;
disk->first_minor = i << part_shift;
disk->fops = &nbd_fops;
disk->private_data = &nbd_dev[i];
sprintf(disk->disk_name, "nbd%d", i);
- set_capacity(disk, 0);
+ nbd_reset(&nbd_dev[i]);
add_disk(disk);
}
--
2.7.0
[PATCH] KVM: remove useless variable in kvm_emulate_cpuid()
Originally, this var('function') was used by trace_kvm_cpuid(), but
the trace_kvm_cpuid() has moved into kvm_cpuid() . From then on, this
var is useless, so we can remove it.
Signed-off-by: Long Peng
---
arch/x86/kvm/cpuid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 6525e92..be0ef88 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -836,9 +836,9 @@ EXPORT_SYMBOL_GPL(kvm_cpuid);
void kvm_emulate_cpuid(struct kvm_vcpu *vcpu)
{
- u32 function, eax, ebx, ecx, edx;
+ u32 eax, ebx, ecx, edx;
- function = eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
+ eax = kvm_register_read(vcpu, VCPU_REGS_RAX);
ecx = kvm_register_read(vcpu, VCPU_REGS_RCX);
kvm_cpuid(vcpu, &eax, &ebx, &ecx, &edx);
kvm_register_write(vcpu, VCPU_REGS_RAX, eax);
--
2.5.0
[PATCH 6/7] nbd: ratelimit error msgs after socket close
From: Dan Streetman
Make the "Attempted send on closed socket" error messages generated in
nbd_request_handler() ratelimited.
When the nbd socket is shutdown, the nbd_request_handler() function emits
an error message for every request remaining in its queue. If the queue
is large, this will spam a large amount of messages to the log. There's
no need for a separate error message for each request, so this patch
ratelimits it.
In the specific case this was found, the system was virtual and the error
messages were logged to the serial port, which overwhelmed it.
Fixes: 4d48a542b427 ("nbd: fix I/O hang on disconnected nbds")
Signed-off-by: Dan Streetman
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index b67500d5b338..4c5d94146aa3 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -580,8 +580,8 @@ static void nbd_request_handler(struct request_queue *q)
req, req->cmd_type);
if (unlikely(!nbd->sock)) {
- dev_err(disk_to_dev(nbd->disk),
- "Attempted send on closed socket\n");
+ dev_err_ratelimited(disk_to_dev(nbd->disk),
+ "Attempted send on closed
socket\n");
req->errors++;
nbd_end_request(nbd, req);
spin_lock_irq(q->queue_lock);
--
2.7.0
[PATCH 7/7] nbd: Create size change events for userspace
The userspace needs to know when nbd devices are ready for use.
Currently no events are created for the userspace which doesn't work for
systemd.
See the discussion here: https://github.com/systemd/systemd/pull/358
This patch uses a central point to setup the nbd-internal sizes. A ioctl
to set a size does not lead to a visible size change. The size of the
block device will be kept at 0 until nbd is connected. As soon as it
connects, the size will be changed to the real value and a uevent is
created. When disconnecting, the blockdevice is set to 0 size and
another uevent is generated.
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 79 +++--
1 file changed, 58 insertions(+), 21 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 4c5d94146aa3..f6b51d76e578 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -100,6 +100,11 @@ static inline struct device *nbd_to_dev(struct nbd_device
*nbd)
return disk_to_dev(nbd->disk);
}
+static bool nbd_is_connected(struct nbd_device *nbd)
+{
+ return !!nbd->task_recv;
+}
+
static const char *nbdcmd_to_ascii(int cmd)
{
switch (cmd) {
@@ -112,6 +117,42 @@ static const char *nbdcmd_to_ascii(int cmd)
return "invalid";
}
+static int nbd_size_clear(struct nbd_device *nbd, struct block_device *bdev)
+{
+ bdev->bd_inode->i_size = 0;
+ set_capacity(nbd->disk, 0);
+ kobject_uevent(&nbd_to_dev(nbd)->kobj, KOBJ_CHANGE);
+
+ return 0;
+}
+
+static void nbd_size_update(struct nbd_device *nbd, struct block_device *bdev)
+{
+ if (!nbd_is_connected(nbd))
+ return;
+
+ bdev->bd_inode->i_size = nbd->bytesize;
+ set_capacity(nbd->disk, nbd->bytesize >> 9);
+ kobject_uevent(&nbd_to_dev(nbd)->kobj, KOBJ_CHANGE);
+}
+
+static int nbd_size_set(struct nbd_device *nbd, struct block_device *bdev,
+ int blocksize, int nr_blocks)
+{
+ int ret;
+
+ ret = set_blocksize(bdev, blocksize);
+ if (ret)
+ return ret;
+
+ nbd->blksize = blocksize;
+ nbd->bytesize = (loff_t)blocksize * (loff_t)nr_blocks;
+
+ nbd_size_update(nbd, bdev);
+
+ return 0;
+}
+
static void nbd_end_request(struct nbd_device *nbd, struct request *req)
{
int error = req->errors ? -EIO : 0;
@@ -401,7 +442,7 @@ static struct device_attribute pid_attr = {
.show = pid_show,
};
-static int nbd_thread_recv(struct nbd_device *nbd)
+static int nbd_thread_recv(struct nbd_device *nbd, struct block_device *bdev)
{
struct request *req;
int ret;
@@ -421,6 +462,8 @@ static int nbd_thread_recv(struct nbd_device *nbd)
return ret;
}
+ nbd_size_update(nbd, bdev);
+
while (1) {
req = nbd_read_stat(nbd);
if (IS_ERR(req)) {
@@ -431,6 +474,8 @@ static int nbd_thread_recv(struct nbd_device *nbd)
nbd_end_request(nbd, req);
}
+ nbd_size_clear(nbd, bdev);
+
device_remove_file(disk_to_dev(nbd->disk), &pid_attr);
nbd->task_recv = NULL;
@@ -707,20 +752,19 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
return err;
}
- case NBD_SET_BLKSIZE:
- nbd->blksize = arg;
- nbd->bytesize &= ~(nbd->blksize-1);
- bdev->bd_inode->i_size = nbd->bytesize;
- set_blocksize(bdev, nbd->blksize);
- set_capacity(nbd->disk, nbd->bytesize >> 9);
- return 0;
+ case NBD_SET_BLKSIZE: {
+ loff_t bsize = nbd->bytesize;
+ do_div(bsize, arg);
+
+ return nbd_size_set(nbd, bdev, arg, bsize);
+ }
case NBD_SET_SIZE:
- nbd->bytesize = arg & ~(nbd->blksize-1);
- bdev->bd_inode->i_size = nbd->bytesize;
- set_blocksize(bdev, nbd->blksize);
- set_capacity(nbd->disk, nbd->bytesize >> 9);
- return 0;
+ return nbd_size_set(nbd, bdev, nbd->blksize,
+ arg / nbd->blksize);
+
+ case NBD_SET_SIZE_BLOCKS:
+ return nbd_size_set(nbd, bdev, nbd->blksize, arg);
case NBD_SET_TIMEOUT:
nbd->xmit_timeout = arg * HZ;
@@ -736,13 +780,6 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
nbd->flags = arg;
return 0;
- case NBD_SET_SIZE_BLOCKS:
- nbd->bytesize = ((u64) arg) * nbd->blksize;
- bdev->bd_inode->i_size = nbd->bytesize;
- set_blocksize(bdev, nbd->blksize);
- set_capacity(nbd->disk, nbd->bytesize >> 9);
- return 0;
-
case NBD_DO_IT: {
struct task_struct *thread;
int error;
@@ -764,7 +801,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd
[PATCH 5/7] nbd: Move flag parsing to a function
nbd changes properties of the blockdevice depending on flags that were
received. This patch moves this flag parsing into a separate function
nbd_parse_flags().
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 34a46c32c24f..b67500d5b338 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -641,6 +641,18 @@ static void nbd_bdev_reset(struct block_device *bdev)
}
}
+static void nbd_parse_flags(struct nbd_device *nbd, struct block_device *bdev)
+{
+ if (nbd->flags & NBD_FLAG_READ_ONLY)
+ set_device_ro(bdev, true);
+ if (nbd->flags & NBD_FLAG_SEND_TRIM)
+ queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, nbd->disk->queue);
+ if (nbd->flags & NBD_FLAG_SEND_FLUSH)
+ blk_queue_flush(nbd->disk->queue, REQ_FLUSH);
+ else
+ blk_queue_flush(nbd->disk->queue, 0);
+}
+
static int nbd_dev_dbg_init(struct nbd_device *nbd);
static void nbd_dev_dbg_close(struct nbd_device *nbd);
@@ -742,15 +754,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
mutex_unlock(&nbd->tx_lock);
- if (nbd->flags & NBD_FLAG_READ_ONLY)
- set_device_ro(bdev, true);
- if (nbd->flags & NBD_FLAG_SEND_TRIM)
- queue_flag_set_unlocked(QUEUE_FLAG_DISCARD,
- nbd->disk->queue);
- if (nbd->flags & NBD_FLAG_SEND_FLUSH)
- blk_queue_flush(nbd->disk->queue, REQ_FLUSH);
- else
- blk_queue_flush(nbd->disk->queue, 0);
+ nbd_parse_flags(nbd, bdev);
thread = kthread_run(nbd_thread_send, nbd, "%s",
nbd_name(nbd));
--
2.7.0
Camel Case
Is camel case discouraged in linux code? I noticed a check for it in checkpatch.pl but it is not one of the default options form scanning. Jeff
[PATCH 3/7] nbd: Timeouts are not user requested disconnects
It may be useful to know in the client that a connection timed out. The
current code returns success for a timeout.
This patch reports the error code -ETIMEDOUT for a timeout.
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 438f4dc549db..2e14e51b5ea3 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -57,6 +57,7 @@ struct nbd_device {
int blksize;
loff_t bytesize;
int xmit_timeout;
+ bool timedout;
bool disconnect; /* a disconnect has been requested by user */
struct timer_list timeout_timer;
@@ -154,10 +155,9 @@ static void nbd_xmit_timeout(unsigned long arg)
if (list_empty(&nbd->queue_head))
return;
- nbd->disconnect = true;
-
spin_lock_irqsave(&nbd->sock_lock, flags);
+ nbd->timedout = true;
if (nbd->sock)
kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
@@ -754,7 +754,10 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
if (max_part > 0)
blkdev_reread_part(bdev);
if (nbd->disconnect) /* user requested, ignore socket errors */
- return 0;
+ error = 0;
+ if (nbd->timedout)
+ error = -ETIMEDOUT;
+
return error;
}
--
2.7.0
[PATCH 1/7] nbd: Fix debugfs error handling
Static checker complains about the implemented error handling. It is
indeed wrong. We don't care about the return values of created debugfs
files.
We only have to check the return values of created dirs for NULL
pointer. If we use a null pointer as parent directory for files, this
may lead to debugfs files in wrong places.
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 55 ++---
1 file changed, 14 insertions(+), 41 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index e4c5cc107934..d61a04155d99 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -892,50 +892,23 @@ static const struct file_operations nbd_dbg_flags_ops = {
static int nbd_dev_dbg_init(struct nbd_device *nbd)
{
struct dentry *dir;
- struct dentry *f;
+
+ if (!nbd_dbg_dir)
+ return -EIO;
dir = debugfs_create_dir(nbd_name(nbd), nbd_dbg_dir);
- if (IS_ERR_OR_NULL(dir)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs dir for '%s'
(%ld)\n",
- nbd_name(nbd), PTR_ERR(dir));
- return PTR_ERR(dir);
+ if (!dir) {
+ dev_err(nbd_to_dev(nbd), "Failed to create debugfs dir for
'%s'\n",
+ nbd_name(nbd));
+ return -EIO;
}
nbd->dbg_dir = dir;
- f = debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_ops);
- if (IS_ERR_OR_NULL(f)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs file
'tasks', %ld\n",
- PTR_ERR(f));
- return PTR_ERR(f);
- }
-
- f = debugfs_create_u64("size_bytes", 0444, dir, &nbd->bytesize);
- if (IS_ERR_OR_NULL(f)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs file
'size_bytes', %ld\n",
- PTR_ERR(f));
- return PTR_ERR(f);
- }
-
- f = debugfs_create_u32("timeout", 0444, dir, &nbd->xmit_timeout);
- if (IS_ERR_OR_NULL(f)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs file
'timeout', %ld\n",
- PTR_ERR(f));
- return PTR_ERR(f);
- }
-
- f = debugfs_create_u32("blocksize", 0444, dir, &nbd->blksize);
- if (IS_ERR_OR_NULL(f)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs file
'blocksize', %ld\n",
- PTR_ERR(f));
- return PTR_ERR(f);
- }
-
- f = debugfs_create_file("flags", 0444, dir, &nbd, &nbd_dbg_flags_ops);
- if (IS_ERR_OR_NULL(f)) {
- dev_err(nbd_to_dev(nbd), "Failed to create debugfs file
'flags', %ld\n",
- PTR_ERR(f));
- return PTR_ERR(f);
- }
+ debugfs_create_file("tasks", 0444, dir, nbd, &nbd_dbg_tasks_ops);
+ debugfs_create_u64("size_bytes", 0444, dir, &nbd->bytesize);
+ debugfs_create_u32("timeout", 0444, dir, &nbd->xmit_timeout);
+ debugfs_create_u32("blocksize", 0444, dir, &nbd->blksize);
+ debugfs_create_file("flags", 0444, dir, &nbd, &nbd_dbg_flags_ops);
return 0;
}
@@ -950,8 +923,8 @@ static int nbd_dbg_init(void)
struct dentry *dbg_dir;
dbg_dir = debugfs_create_dir("nbd", NULL);
- if (IS_ERR(dbg_dir))
- return PTR_ERR(dbg_dir);
+ if (!dbg_dir)
+ return -EIO;
nbd_dbg_dir = dbg_dir;
--
2.7.0
[PATCH 2/7] nbd: Remove signal usage
As discussed on the mailing list, the usage of signals for timeout
handling has a lot of potential issues. The nbd driver used for some
time signals for timeouts. These signals where able to get the threads
out of the blocking socket operations.
This patch removes all signal usage and uses a socket shutdown instead.
The socket descriptor itself is cleared later when the whole nbd device
is closed.
The tasks_lock is removed as we do not depend on this anymore. Instead
a new lock for the socket is introduced so we can safely work with the
socket in the timeout handler outside of the two main threads.
Cc: Oleg Nesterov
Cc: Christoph Hellwig
Signed-off-by: Markus Pargmann
Reviewed-by: Christoph Hellwig
---
drivers/block/nbd.c | 126
1 file changed, 48 insertions(+), 78 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index d61a04155d99..438f4dc549db 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -60,7 +60,8 @@ struct nbd_device {
bool disconnect; /* a disconnect has been requested by user */
struct timer_list timeout_timer;
- spinlock_t tasks_lock;
+ /* protects initialization and shutdown of the socket */
+ spinlock_t sock_lock;
struct task_struct *task_recv;
struct task_struct *task_send;
@@ -129,13 +130,20 @@ static void nbd_end_request(struct nbd_device *nbd,
struct request *req)
*/
static void sock_shutdown(struct nbd_device *nbd)
{
- if (!nbd->sock)
+ spin_lock_irq(&nbd->sock_lock);
+
+ if (!nbd->sock) {
+ spin_unlock_irq(&nbd->sock_lock);
return;
+ }
dev_warn(disk_to_dev(nbd->disk), "shutting down socket\n");
kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
+ sockfd_put(nbd->sock);
nbd->sock = NULL;
- del_timer_sync(&nbd->timeout_timer);
+ spin_unlock_irq(&nbd->sock_lock);
+
+ del_timer(&nbd->timeout_timer);
}
static void nbd_xmit_timeout(unsigned long arg)
@@ -148,17 +156,15 @@ static void nbd_xmit_timeout(unsigned long arg)
nbd->disconnect = true;
- spin_lock_irqsave(&nbd->tasks_lock, flags);
+ spin_lock_irqsave(&nbd->sock_lock, flags);
- if (nbd->task_recv)
- force_sig(SIGKILL, nbd->task_recv);
- if (nbd->task_send)
- force_sig(SIGKILL, nbd->task_send);
+ if (nbd->sock)
+ kernel_sock_shutdown(nbd->sock, SHUT_RDWR);
- spin_unlock_irqrestore(&nbd->tasks_lock, flags);
+ spin_unlock_irqrestore(&nbd->sock_lock, flags);
- dev_err(nbd_to_dev(nbd), "Connection timed out, killed receiver and
sender, shutting down connection\n");
+ dev_err(nbd_to_dev(nbd), "Connection timed out, shutting down
connection\n");
}
/*
@@ -171,7 +177,6 @@ static int sock_xmit(struct nbd_device *nbd, int send, void
*buf, int size,
int result;
struct msghdr msg;
struct kvec iov;
- sigset_t blocked, oldset;
unsigned long pflags = current->flags;
if (unlikely(!sock)) {
@@ -181,11 +186,6 @@ static int sock_xmit(struct nbd_device *nbd, int send,
void *buf, int size,
return -EINVAL;
}
- /* Allow interception of SIGKILL only
-* Don't allow other signals to interrupt the transmission */
- siginitsetinv(&blocked, sigmask(SIGKILL));
- sigprocmask(SIG_SETMASK, &blocked, &oldset);
-
current->flags |= PF_MEMALLOC;
do {
sock->sk->sk_allocation = GFP_NOIO | __GFP_MEMALLOC;
@@ -212,7 +212,6 @@ static int sock_xmit(struct nbd_device *nbd, int send, void
*buf, int size,
buf += result;
} while (size > 0);
- sigprocmask(SIG_SETMASK, &oldset, NULL);
tsk_restore_flags(current, pflags, PF_MEMALLOC);
if (!send && nbd->xmit_timeout)
@@ -406,23 +405,18 @@ static int nbd_thread_recv(struct nbd_device *nbd)
{
struct request *req;
int ret;
- unsigned long flags;
BUG_ON(nbd->magic != NBD_MAGIC);
sk_set_memalloc(nbd->sock->sk);
- spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = current;
- spin_unlock_irqrestore(&nbd->tasks_lock, flags);
ret = device_create_file(disk_to_dev(nbd->disk), &pid_attr);
if (ret) {
dev_err(disk_to_dev(nbd->disk), "device_create_file failed!\n");
- spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = NULL;
- spin_unlock_irqrestore(&nbd->tasks_lock, flags);
return ret;
}
@@ -439,19 +433,7 @@ static int nbd_thread_recv(struct nbd_device *nbd)
device_remove_file(disk_to_dev(nbd->disk), &pid_attr);
- spin_lock_irqsave(&nbd->tasks_lock, flags);
nbd->task_recv = NULL;
- spin_unlock_irqrestore(&nbd->tasks_lock, flags);
-
- if (signal_pending(current)) {
-
Re: [PATCH 2/6] perf, tools, stat: Implement CSV metrics output
On Wed, Feb 17, 2016 at 02:44:01PM -0800, Andi Kleen wrote:
SNIP
> ---
> tools/perf/builtin-stat.c | 76
> ---
> 1 file changed, 72 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 86289df..6c2c1d2 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -739,6 +739,8 @@ struct outstate {
> FILE *fh;
> bool newline;
> const char *prefix;
> + int nfields;
> + u64 run, ena;
what are outstate's ena and run being used for?
thanks,
jirka
[PATCH] mm,oom: remove shortcuts for SIGKILL and PF_EXITING cases
Currently, sending SIGKILL to all user processes sharing the same memory is omitted by three locations. But they should be removed due to possible OOM livelock sequence shown below. About setting TIF_MEMIE on current->mm && fatal_signal_pending(current) at out_of_memory(): There are two thread groups named P1 and P2 that are created using clone(!CLONE_SIGHAND && CLONE_VM) and one independent thread group named P3. A sequence shown below is possible. -- P1 P2 P3 Do something that invokes a __GFP_FS memory allocation (e.g. page fault). Calls mmap(). Calls kill(P1, SIGKILL). Arrives at vm_mmap_pgoff(). Calls down_write(&mm->mmap_sem). Sends SIGKILL to P1. fatal_signal_pending(P1) becomes true. Calls do_mmap_pgoff(). Calls out_of_memory(). Gets TIF_MEMDIE. Calls out_of_memory(). oom_scan_process_thread() returns OOM_SCAN_ABORT. Arrives at do_exit(). Calls down_read(&mm->mmap_sem) at exit_mm(). oom_scan_process_thread() still returns OOM_SCAN_ABORT. -- P1 is waiting for P2 to call up_write(&mm->mmap_sem) but P2 won't give up memory allocation because fatal_signal_pending(P2) is false. This race condition can be avoided if P1 sent SIGKILL to P2 when P1 called out_of_memory(). About setting TIF_MEMIE on current->mm && task_will_free_mem(current) at out_of_memory(): There are two thread groups named P1 and P2 that are created using clone(!CLONE_SIGHAND && CLONE_VM). A sequence shown below is possible. -- P1 P2 Calls _exit(0). Calls mmap(). Arrives at vm_mmap_pgoff(). Calls down_write(&mm->mmap_sem). Arrives at do_exit(). Gets PF_EXITING via exit_signals(). Calls tty_audit_exit(). Do a GFP_KERNEL allocation from tty_audit_log(). Calls out_of_memory(). Gets TIF_MEMDIE. Calls out_of_memory(). oom_scan_process_thread() returns OOM_SCAN_ABORT. Calls down_read(&mm->mmap_sem) at exit_mm(). oom_scan_process_thread() still returns OOM_SCAN_ABORT. -- P1 is waiting for P2 to call up_write(&mm->mmap_sem) but P2 won't give up memory allocation because fatal_signal_pending(P2) is false. This race condition can be avoided if P1 sent SIGKILL to P2 when P1 called out_of_memory(). About setting TIF_MEMIE on p->mm && task_will_free_mem(p) at oom_kill_process(): There are two thread groups named P1 and P2 that are created using clone(!CLONE_SIGHAND && CLONE_VM) and one independent thread group named P3. A sequence shown below is possible. -- P1 P2 Calls _exit(0). Calls mmap(). Arrives at vm_mmap_pgoff(). Calls down_write(&mm->mmap_sem). Arrives at do_exit(). Gets PF_EXITING via exit_signals(). Calls down_read(&mm->mmap_sem) at exit_mm(). Calls do_mmap_pgoff(). Calls out_of_memory(). select_bad_process() returns P1. oom_kill_process() sets TIF_MEMDIE on P1. oom_scan_process_thread() returns OOM_SCAN_ABORT. -- P1 is waiting for P2 to call up_write(&mm->mmap_sem) but P2 won't give up memory allocation because fatal_signal_pending(P2) is false. This race condition can be avoided if P2 sent SIGKILL to P2 when P2 called out_of_memory(). About setting TIF_MEMIE on fatal_signal_pending(current) at mem_cgroup_out_of_memory(): mem_cgroup_out_of_memory() is called from a lockless context via mem_cgroup_oom_synchronize() called from pagefault_out_of_memory() is talking about only current thread. If global OOM condition follows before memcg OOM condition is solved, the same problem will occur. About setting TIF_MEMIE on task_will_free_mem(current) at mem_cgroup_out_of_memory(): I don't know whether it is possible to call mem_cgroup_out_of_memory() between getting PF_EXITING and doing current->mm = NULL. But if it is possible to call, then the same problem will occur. And since removing these shortcuts breaks a wrong and optimistic assumption in oom_kill_process() /* * Kill all user processes sharing victim->mm in other thread groups, if * any. They don't get access to memory reserves, though, to avoid * depletion of all memory. This prevents mm->mmap_sem livelock when an * oom killed thread cannot exit because it requires the semaphore and * its contended by another thread trying to allocate memory itself. * That thread will now get access to memory reserves since it has a * pending fatal signal. */ set TIF_MEMDIE on all threads in thread groups which got SIGKILL by the OOM killer. This will help getting threads doing !__GFP_FS allocations which are not allowed to call out_of_memory() (w
Re: [PATCH 2/6] perf, tools, stat: Implement CSV metrics output
On Thu, Feb 18, 2016 at 06:39:21PM +0100, Andi Kleen wrote: > > Where before it wasn't there: > > > > cat /tmp/before > > 0.282628,,task-clock,282628,100.00 > > 1,,context-switches,282628,100.00 > > 0,,cpu-migrations,282628,100.00 > > 52,,page-faults,282628,100.00 > > 861213,,cycles,285354,100.00 > > ,,stalled-cycles-frontend,0,100.00 > > ,,stalled-cycles-backend,0,100.00 > > 686082,,instructions,285354,100.00 > > 137846,,branches,285354,100.00 > > 7142,,branch-misses,285354,100.00 > > This is intentional. See the standard perf output: > > > 521,232 instructions #0.63 insns per cycle > > #1.13 stalled cycles > per insn > > So this line has multiple metrics. In CSV this is expressed as a mostly empty > line. it's intentional if you have data from stalled cycles counter on cpu where this one is non supported you get blank line: 0.186177,,task-clock,186177,100.00,0.448,CPUs utilized 0,,context-switches,186177,100.00,0.000,K/sec 0,,cpu-migrations,186177,100.00,0.000,K/sec 43,,page-faults,186177,100.00,0.231,M/sec 567286,,cycles,187628,100.00,3.047,GHz ,,stalled-cycles-frontend,0,100.00 ,,stalled-cycles-backend,0,100.00 456664,,instructions,187628,100.00,0.80,insn per cycle 89069,,branches,187628,100.00,478.410,M/sec 3360,,branch-misses,187628,100.00,3.77,of all branches which I think is wrong and we should not print jirka
Re: [PATCH] mfd: fsl-imx25-tsadc: select IRQ_DOMAIN
On Tuesday 16 February 2016 15:54:24 Arnd Bergmann wrote:
> The newly added tsadc code use irq domains, but it can be enabled
> when they are disabled in Kconfig:
>
> drivers/mfd/fsl-imx25-tsadc.c:41:22: error: implicit declaration of function
> 'irq_find_mapping' [-Werror=implicit-function-declaration]
>generic_handle_irq(irq_find_mapping(tsadc->domain, 1));
> drivers/mfd/fsl-imx25-tsadc.c: In function 'mx25_tsadc_setup_irq':
> drivers/mfd/fsl-imx25-tsadc.c:80:18: error: implicit declaration of function
> 'irq_domain_add_simple' [-Werror=implicit-function-declaration]
>
> This adds a 'select IRQ_DOMAIN' code, like we have it in all other
> drivers with this requirement.
>
> Signed-off-by: Arnd Bergmann
> Fixes: e2fccf5c1515 ("mfd: fsl-imx25-tsadc: Register touchscreen ADC driver")
Thanks,
Reviewed-by: Markus Pargmann
Best Regards,
Markus
> ---
> drivers/mfd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aa21dc55eb15..8cab3ecca8fc 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -300,6 +300,7 @@ config MFD_MC13XXX_I2C
> config MFD_MX25_TSADC
> tristate "Freescale i.MX25 integrated Touchscreen and ADC unit"
> select REGMAP_MMIO
> + select IRQ_DOMAIN
> depends on (SOC_IMX25 && OF) || COMPILE_TEST
> help
> Enable support for the integrated Touchscreen and ADC unit of the
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] Documentation/memory-barriers: fix wrong comment in example
On Sun, Feb 21, 2016 at 2:25 PM, Paul E. McKenney wrote: > On Sun, Feb 21, 2016 at 07:50:19AM +0900, SeongJae Park wrote: >> On Sun, Feb 21, 2016 at 4:57 AM, Paul E. McKenney >> wrote: >> > On Sat, Feb 20, 2016 at 03:01:08PM +0900, SeongJae Park wrote: >> >> There is wrong comment in example for compiler store omit behavior. It >> >> shows example of the problem and than problem solved version code. >> >> However, the comment in the solved version is still same with not solved >> >> version. Fix the wrong statement with this commit. >> >> >> >> Signed-off-by: SeongJae Park >> > >> > Hmmm... The code between the two stores of zero to "a" is intended to >> > remain the same in the broken and fixed versions. So the only change >> > is from "a = 0" to "WRITE_ONCE(a, 0)". Note that it is some other >> > CPU that did the third store to "a". >> >> Agree, of course. >> >> > >> > Or am I missing your point here? >> >> My point is about the comment. >> I thought the comment in broken version is saying "Below line(a = 0) says >> it will store to variable 'a', but it will not in actual because a compiler >> can >> omit it". >> However, in fixed version, because the compiler cannot omit the store >> now, I thought the comment also should be changed to say the difference >> between broken and fixed version. >> >> If I am understanding anything wrong, please let me know. > > Hmmm... The intent of the comment is to act as a placeholder for > arbitrary code that does not affect the value of "a". The current > comment is clearly not doing that for you. Possible changes include: > > o Adding test to the comment making the intent more clear. > o Replacing the comment with a function call, perhaps to > does_not_change_a() or some similar name. > o Keeping the current comment, but adding a call to something > like does_not_change_a() after it. > > Other thoughts? Ah, now I understood the original intent. Thank you for the kind explanation. I think your third option will be most helpful for me. How about the patch below? BTW, the problem looks trivial rather than critical. If you think so, feel free to ignore my patch, please. Thanks, SeongJae Park == >3 == >From 77e0b1c77d64c358b329b097cffcdacd2c484867 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Sun, 21 Feb 2016 15:18:16 +0900 Subject: [PATCH] Documentation/memory-barriers: polish compiler store omit example Comments of examples about compiler store omit in memory-barriers.txt is about code that could be possible at that point. However, someone could interpret the comment as an explanation about below line. This commit exploits the intent more explicitly by adding a function call below the comment. Signed-off-by: SeongJae Park --- Documentation/memory-barriers.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 904ee42..3a17d66 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1460,6 +1460,7 @@ of optimizations: a = 0; /* Code that does not store to variable a. */ + does_not_change_a(); a = 0; The compiler sees that the value of variable 'a' is already zero, so @@ -1472,6 +1473,7 @@ of optimizations: WRITE_ONCE(a, 0); /* Code that does not store to variable a. */ + does_not_change_a(); WRITE_ONCE(a, 0); (*) The compiler is within its rights to reorder memory accesses unless -- 1.9.1 > > Thanx, Paul > >> Thanks, >> SeongJae Park >> >> > >> > Thanx, Paul >> > >> >> --- >> >> Documentation/memory-barriers.txt | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/Documentation/memory-barriers.txt >> >> b/Documentation/memory-barriers.txt >> >> index 061ff29..b4754c7 100644 >> >> --- a/Documentation/memory-barriers.txt >> >> +++ b/Documentation/memory-barriers.txt >> >> @@ -1471,7 +1471,7 @@ of optimizations: >> >> wrong guess: >> >> >> >> WRITE_ONCE(a, 0); >> >> - /* Code that does not store to variable a. */ >> >> + /* Code that does store to variable a. */ >> >> WRITE_ONCE(a, 0); >> >> >> >> (*) The compiler is within its rights to reorder memory accesses unless >> >> -- >> >> 1.9.1 >> >> >> > >> >
Re: [PATCH] Revert "regulator: tps65217: remove tps65217.dtsi file"
Hello Tony, Peter, Am 19.02.2016 um 18:04 schrieb Tony Lindgren: * Peter Ujfalusi [160219 06:14]: This reverts commit 8e6ebfaa9b384088002baa10f7534efa73a0794e. Without the patch reverted regulators will not work. This prevents MMC to be working for example so the boards can not boot to MMC rootfs. Tested it on beaglebone white and bisect also points to the reverted commit. The issue can be also fixed by adding "regulator-compatible =" to all board dts file for the regulators. Signed-off-by: Peter Ujfalusi --- Hi, I have noticed that bbw did not find the MMC with linux-next, but it turns out that even 4.5-rc4 is behaving the same way. I have run bisect and with this revert patch I can boot up fine. To be honest I don't know why the tps65217.dtsi has been deleted in the first place. I think initially the only real issue was the naming. The tps65217.dtsi file should be just renamed to tps65217-am335x.dtsi to make it clear that this configuration is commonly used for most am335x boards. I'll apply this revert into omap-for-v4.5/fixes as it fixes a regression. Sorry for breaking ... but I have no bbw hw for testing ... (This is maybe a reason for having something like an automated testsystem, see an example/proposal here: https://github.com/hsdenx/tbot see a demo for automated tests (running on a raspberry pi at my home in hungary, boards are in munich/germany) http://xeidos.ddns.net/buildbot/tgrid ) But I removed this file as Mark Brown suggested it, see: https://lkml.org/lkml/2015/10/21/581 So please introduce a "tps65217-am335x.dtsi" file ... Mark? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Re: [PATCHv6 1/3] rdmacg: Added rdma cgroup controller
On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote: > On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote: > > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote: > > Can you place this ifdef before declaring struct rdma_cgroup? > Yes. I missed out this cleanup. Done locally now. Great, additional thing which spotted my attention was related to declaring and using the new cgroups functions. There are number of places where you protected the calls by specific ifdefs in the IB/core c-files and not in h-files as it is usually done. > > > Thanks
Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote: > > > > > > +#if !(defined(FW_CFG_CTRL_OFF) && defined(FW_CTRL_DATA_OFF)) > > > +# if (defined(CONFIG_ARM) || defined(CONFIG_ARM64)) > > > +# define FW_CFG_CTRL_OFF 0x08 > > > +# define FW_CFG_DATA_OFF 0x00 > > > +# elif (defined(CONFIG_PPC_PMAC) || defined(CONFIG_SPARC32)) /* > > > ppc/mac,sun4m */ > > > +# define FW_CFG_CTRL_OFF 0x00 > > > +# define FW_CFG_DATA_OFF 0x02 > > > +# elif (defined(CONFIG_X86) || defined(CONFIG_SPARC64)) /* x86, sun4u */ > > > +# define FW_CFG_CTRL_OFF 0x00 > > > +# define FW_CFG_DATA_OFF 0x01 > > > +# else > > > +# warning "QEMU FW_CFG may not be available on this architecture!" > > > +# define FW_CFG_CTRL_OFF 0x00 > > > +# define FW_CFG_DATA_OFF 0x01 > > > > Better not try hacks like this, they are hard > > to support down the road. Please only list what is tested and > > actually exposed by QEMU. > > I was looking for a standard way to advertise register offsets within > the ioport or mmio region assigned to fw_cfg, but right now the answer > is "there isn't one", and "register offsets are an arch specific > detail". As such, the only reasonable way I saw was to copy the same > values used in the QEMU source. > > See also: > https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg05037.html > > Thanks much, > --Gabriel My point is you don't know what will qemu do on these other arches which do not at the moment have fw cfg. So don't try to guess! -- MST
Re: [PATCH v8 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote: > > So for all arches which support ACPI, I think this driver > > should just rely on ACPI. > > There was a discussion about that a few versions ago, and IIRC the > conclusion was not to expect the firmware to contend for fw_cfg access > after the guest kernel boots: > > https://lkml.org/lkml/2015/10/5/283 Interesting. Igor wanted to do this again recently ... I'll think it over and get back to you/list on this. > (I even had a prototype version doing what you suggested, but per the above > reference decided to drop it -- which IMHO is for the better, since otherwise > I'd have had to ifdef between ACPI and non-ACPI versions of the driver -- > see https://lkml.org/lkml/2015/11/4/534 ) I'm not sure I get it - won't you only ifdef the accessor function? -- MST
[PATCH v7 2/2] ASoC: sunxi: Add support for the SPDIF block
From: Marcus Cooper The sun4i, sun5i and sun7i SoC families have an SPDIF block which is capable of playback and capture. This patch enables the playback of this block for the sun4i families. Signed-off-by: Marcus Cooper --- sound/soc/sunxi/Kconfig | 8 + sound/soc/sunxi/Makefile | 1 + sound/soc/sunxi/sun4i-spdif.c | 542 ++ 3 files changed, 551 insertions(+) create mode 100644 sound/soc/sunxi/sun4i-spdif.c diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig index 84c72ec..ae42294 100644 --- a/sound/soc/sunxi/Kconfig +++ b/sound/soc/sunxi/Kconfig @@ -8,4 +8,12 @@ config SND_SUN4I_CODEC Select Y or M to add support for the Codec embedded in the Allwinner A10 and affiliated SoCs. +config SND_SUN4I_SPDIF + tristate "Allwinner A10 SPDIF Support" + depends on OF + select SND_SOC_GENERIC_DMAENGINE_PCM + select REGMAP_MMIO + help + Say Y or M to add support for the S/PDIF audio block in the Allwinner + A10 and affiliated SoCs. endmenu diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile index ea8a08c..8f5e889 100644 --- a/sound/soc/sunxi/Makefile +++ b/sound/soc/sunxi/Makefile @@ -1,2 +1,3 @@ obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o +obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c new file mode 100644 index 000..baa2696 --- /dev/null +++ b/sound/soc/sunxi/sun4i-spdif.c @@ -0,0 +1,542 @@ +/* + * ALSA SoC SPDIF Audio Layer + * + * Copyright 2015 Andrea Venturi + * Copyright 2015 Marcus Cooper + * + * Based on the Allwinner SDK driver, released under the GPL. + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineSUN4I_SPDIF_CTL (0x00) + #define SUN4I_SPDIF_CTL_MCLKDIV(v) ((v) << 4) /* v even */ + #define SUN4I_SPDIF_CTL_MCLKOUTEN BIT(2) + #define SUN4I_SPDIF_CTL_GEN BIT(1) + #define SUN4I_SPDIF_CTL_RESET BIT(0) + +#define SUN4I_SPDIF_TXCFG (0x04) + #define SUN4I_SPDIF_TXCFG_SINGLEMOD BIT(31) + #define SUN4I_SPDIF_TXCFG_ASS BIT(17) + #define SUN4I_SPDIF_TXCFG_NONAUDIO BIT(16) + #define SUN4I_SPDIF_TXCFG_TXRATIO(v)((v) << 4) + #define SUN4I_SPDIF_TXCFG_TXRATIO_MASK GENMASK(8, 4) + #define SUN4I_SPDIF_TXCFG_FMTRVDGENMASK(3, 2) + #define SUN4I_SPDIF_TXCFG_FMT16BIT (0 << 2) + #define SUN4I_SPDIF_TXCFG_FMT20BIT (1 << 2) + #define SUN4I_SPDIF_TXCFG_FMT24BIT (2 << 2) + #define SUN4I_SPDIF_TXCFG_CHSTMODE BIT(1) + #define SUN4I_SPDIF_TXCFG_TXEN BIT(0) + +#define SUN4I_SPDIF_RXCFG (0x08) + #define SUN4I_SPDIF_RXCFG_LOCKFLAG BIT(4) + #define SUN4I_SPDIF_RXCFG_CHSTSRC BIT(3) + #define SUN4I_SPDIF_RXCFG_CHSTCPBIT(1) + #define SUN4I_SPDIF_RXCFG_RXEN BIT(0) + +#define SUN4I_SPDIF_TXFIFO (0x0C) + +#define SUN4I_SPDIF_RXFIFO (0x10) + +#define SUN4I_SPDIF_FCTL (0x14) + #define SUN4I_SPDIF_FCTL_FIFOSRCBIT(31) + #define SUN4I_SPDIF_FCTL_FTXBIT(17) + #define SUN4I_SPDIF_FCTL_FRXBIT(16) + #define SUN4I_SPDIF_FCTL_TXTL(v)((v) << 8) + #define SUN4I_SPDIF_FCTL_TXTL_MASK GENMASK(12, 8) + #define SUN4I_SPDIF_FCTL_RXTL(v)((v) << 3) + #define SUN4I_SPDIF_FCTL_RXTL_MASK GENMASK(7, 3) + #define SUN4I_SPDIF_FCTL_TXIM BIT(2) + #define SUN4I_SPDIF_FCTL_RXOM(v)((v) << 0) + #define SUN4I_SPDIF_FCTL_RXOM_MASK GENMASK(1, 0) + +#define SUN4I_SPDIF_FSTA (0x18) + #define SUN4I_SPDIF_FSTA_TXEBIT(14) + #define SUN4I_SPDIF_FSTA_TXECNTSHT (8) + #define SUN4I_SPDIF_FSTA_RXABIT(6) + #define SUN4I_SPDIF_FSTA_RXACNTSHT (0) + +#define SUN4I_SPDIF_INT(0x1C) + #define SUN4I_SPDIF_INT_RXLOCKENBIT(18) + #define SUN4I_SPDIF_INT
Re: [PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+
no problem, let me submit another patch
> 在 2016年2月20日，02:02，Tony Lindgren 写道：
>
> Hi,
>
> * Yong Li [151228 20:12]:
>> Based on the below
>> commit ae3c99a26c60 ("ARM: 7806/1: allow DEBUG_UNCOMPRESS for Tegra"),
>> change the .data section to .text section,
>> to enable DEBUG_UNCOMPRESS for OMAP2+ platforms
>> Tested okay using BeagleBone Black
>
> Sorry for the delay, I just noticed this one while looking
> through my inbox for pending patches.
>
> I think we should first simplify things by moving things over
> to use the generic DEBUG_UART_8250 code where the addresses
> need to be specified in the .config. It's been on my list of
> things to do for quite a while but I keep getting interrupted.
>
> My guess is that if we do that, this patch is no longer
> needed :) Yong, care to take a look at that?
>
> Regards,
>
> Tony
>
>> Signed-off-by: Yong Li
>> ---
>> arch/arm/Kconfig.debug | 2 +-
>> arch/arm/include/debug/omap2plus.S | 13 ++---
>> 2 files changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
>> index 259c0ca..e5ae36a 100644
>> --- a/arch/arm/Kconfig.debug
>> +++ b/arch/arm/Kconfig.debug
>> @@ -1596,7 +1596,7 @@ config DEBUG_UART_8250_FLOW_CONTROL
>> config DEBUG_UNCOMPRESS
>>bool
>>depends on ARCH_MULTIPLATFORM || PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
>> -default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART && \
>> +default y if DEBUG_LL && (!DEBUG_OMAP2PLUS_UART || !ZBOOT_ROM) && \
>> (!DEBUG_TEGRA_UART || !ZBOOT_ROM)
>>help
>> This option influences the normal decompressor output for
>> diff --git a/arch/arm/include/debug/omap2plus.S
>> b/arch/arm/include/debug/omap2plus.S
>> index 6d867ae..12421f9 100644
>> --- a/arch/arm/include/debug/omap2plus.S
>> +++ b/arch/arm/include/debug/omap2plus.S
>> @@ -58,11 +58,18 @@
>>
>> #define UART_OFFSET(addr)((addr) & 0x00ff)
>>
>> +#if defined(ZIMAGE)
>> +omap_uart_phys:.word0
>> +omap_uart_virt:.word0
>> +omap_uart_lsr:.word0
>> +#else
>> +
>>.pushsection .data
>> -omap_uart_phys:.word0
>> -omap_uart_virt:.word0
>> -omap_uart_lsr:.word0
>> +omap_uart_phys:.word0
>> +omap_uart_virt:.word0
>> +omap_uart_lsr:.word0
>>.popsection
>> +#endif
>>
>>.macroaddruart, rp, rv, tmp
>>
>> --
>> 2.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
Re: [PATCH] ARM: OMAP2+: allow DEBUG_UNCOMPRESS for OMAP2+
* LIYONG [160221 04:20]: > no problem, let me submit another patch OK thanks! Tony
[PATCH RESEND] TTY, devpts: document pty count limiting
Logic has been changed in kernel 3.4 by commit e9aba5158a80
("tty: rework pty count limiting") but still not documented.
Sysctl kernel.pty.max works as global limit, kernel.pty.reserve ptys
are reserved for initial devpts instance (mounted without "newinstance").
Per-instance limit also could be set by mount option "max=%d".
Signed-off-by: Konstantin Khlebnikov
---
Documentation/filesystems/devpts.txt |9 +
Documentation/sysctl/kernel.txt |1 +
2 files changed, 10 insertions(+)
diff --git a/Documentation/filesystems/devpts.txt
b/Documentation/filesystems/devpts.txt
index 68dffd87f9b7..30d2fcb32f72 100644
--- a/Documentation/filesystems/devpts.txt
+++ b/Documentation/filesystems/devpts.txt
@@ -51,6 +51,15 @@ where 'ns_exec -cm /bin/bash' calls clone() with CLONE_NEWNS
flag and execs
/bin/bash in the child process. A pty created by the sshd is not visible in
the original mount of /dev/pts.
+Total count of pty pairs in all instances is limited by sysctls:
+kernel.pty.max = 4096 - global limit
+kernel.pty.reserve = 1024 - reserve for initial instance
+kernel.pty.nr - current count of ptys
+
+Per-instance limit could be set by adding mount option "max=".
+This feature was added in kernel 3.4 together with sysctl kernel.pty.reserve.
+In kernels older than 3.4 sysctl kernel.pty.max works as per-instance limit.
+
User-space changes
--
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index a93b414672a7..d05e70b7d8dd 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -64,6 +64,7 @@ show up in /proc/sys/kernel:
- printk_delay
- printk_ratelimit
- printk_ratelimit_burst
+- pty ==> Documentation/filesystems/devpts.txt
- randomize_va_space
- real-root-dev ==> Documentation/initrd.txt
- reboot-cmd [ SPARC only ]
Re: [PATCH] staging: xgifb: Fix comment style
Hello, On Sat, Feb 20, 2016 at 03:38:15PM -0800, Kroah-Hartman wrote: >On Wed, Feb 17, 2016 at 02:53:34PM +0800, Bo YU wrote: >> Fix comments to use trailing */ on separate lines. >> >> Signed-off-by: YU BO >> --- >> drivers/staging/xgifb/vb_init.c | 10 +- >> 1 file changed, 5 insertions(+), 5 deletions(-) > >Patch doesn't apply :( I don't know that whether i am doing wrong something with git. Because when i run `git am the-codingfixed-patch` ,it reports error. But run `patch -p1 the-codingfixed-patch` it is ok. Perhaps i am wrong with others. Could you tell me a little hit? Sorry for the noisy.:) -- Best Regards
Re: 4.4-final: 28 bioset threads on small notebook
On Sat, Feb 20, 2016 at 09:55:19PM +0100, Pavel Machek wrote: > Hi! > > > > > You're directing this concern to the wrong person. > > > > > > > > I already told you DM is _not_ contributing any extra "bioset" threads > > > > (ever since commit dbba42d8a). > > > > > > Well, sorry about that. Note that l-k is on the cc list, so hopefully > > > the right person sees it too. > > > > > > Ok, let me check... it seems that > > > 54efd50bfd873e2dbf784e0b21a8027ba4299a3e is responsible, thus Kent > > > Overstreet is to blame. > > > > > > Um, and you acked the patch, so you are partly responsible. > > > > You still haven't shown you even understand the patch so don't try to > > blame me for one aspect you don't like. > > Well, I don't have to understand the patch to argue its wrong. > > > > > But in general, these "bioset" threads are a side-effect of the > > > > late-bio-splitting support. So is your position on it: "I don't like > > > > that feature if it comes at the expense of adding resources I can _see_ > > > > for something I (naively?) view as useless"? > > > > > > > Just seems... naive... but you could be trying to say something else > > > > entirely. > > > > > > > Anyway, if you don't like something: understand why it is there and then > > > > try to fix it to your liking (without compromising why it was there to > > > > begin with). > > > > > > Well, 28 kernel threads on a notebook is a bug, plain and simple. Do > > > you argue it is not? > > > > Just implies you have 28 request_queues right? You clearly have > > something else going on on your notebook than the average notebook > > user. > > I'm not using the modules, but otherwise I'm not doing anything > special. How many request_queues should I expect? How many do you have > on your notebook? It's one rescuer thread per bio_set, not one per request queue, so 28 is more than I'd expect but there's lots of random bio_sets so it's not entirely unexpected. It'd be better to have the rescuers be per request_queue, just someone is going to have to write the code.
[PATCH v7 1/2] ASoC: sunxi :add sun4i SPDIF dt bindings
From: Marcus Cooper
Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10 and A20 SoCs.
Signed-off-by: Marcus Cooper
---
.../bindings/sound/sunxi,sun4i-spdif.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
new file mode 100644
index 000..13503aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt
@@ -0,0 +1,39 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+For now only playback is supported.
+
+Required properties:
+
+ - compatible : should be one of the following:
+- "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+
+ - reg: Offset and length of the register set for the
device.
+
+ - interrupts : Contains the spdif interrupt.
+
+ - dmas : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+ - dma-names : Two dmas have to be defined, "tx" and "rx".
+
+ - clocks : Contains an entry for each entry in clock-names.
+
+ - clock-names: Includes the following entries:
+ "apb" clock for the spdif bus.
+ "spdif" clock for spdif controller.
+
+Example:
+
+spdif: spdif@01c21000 {
+ compatible = "allwinner,sun4i-a10-spdif";
+ reg = <0x01c21000 0x40>;
+ interrupts = <13>;
+ clocks = <&apb0_gates 1>, <&spdif_clk>;
+ clock-names = "apb", "spdif";
+ dmas = <&dma 0 2>, <&dma 0 2>;
+ dma-names = "rx", "tx";
+ status = "okay";
+};
--
2.7.1
[PATCH] ubifs: Implement O_TMPFILE
This patchs adds O_TMPFILE support to UBIFS.
Signed-off-by: Richard Weinberger
---
fs/ubifs/dir.c | 71 ++
1 file changed, 71 insertions(+)
diff --git a/fs/ubifs/dir.c b/fs/ubifs/dir.c
index 795992a..660eefe 100644
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -301,6 +301,76 @@ out_budg:
return err;
}
+static int ubifs_tmpfile(struct inode *dir, struct dentry *dentry,
+umode_t mode)
+{
+ struct inode *inode;
+ struct ubifs_info *c = dir->i_sb->s_fs_info;
+ struct ubifs_budget_req req = { .new_ino = 1, .new_dent = 1};
+ struct ubifs_budget_req ino_req = { .dirtied_ino = 1 };
+ struct ubifs_inode *ui, *dir_ui = ubifs_inode(dir);
+ int err, instantiated = 0;
+
+ /*
+* Budget request settings: new dirty inode, new direntry,
+* budget for dirtied inode will be released via ubifs_evict_inode().
+*/
+
+ dbg_gen("dent '%pd', mode %#hx in dir ino %lu",
+ dentry, mode, dir->i_ino);
+
+ err = ubifs_budget_space(c, &req);
+ if (err)
+ return err;
+
+ err = ubifs_budget_space(c, &ino_req);
+ if (err) {
+ ubifs_release_budget(c, &req);
+ return err;
+ }
+
+ inode = ubifs_new_inode(c, dir, mode);
+ if (IS_ERR(inode)) {
+ err = PTR_ERR(inode);
+ goto out_budg;
+ }
+ ui = ubifs_inode(inode);
+
+ err = ubifs_init_security(dir, inode, &dentry->d_name);
+ if (err)
+ goto out_inode;
+
+ mutex_lock(&ui->ui_mutex);
+ insert_inode_hash(inode);
+ d_tmpfile(dentry, inode);
+ ubifs_assert(ui->dirty);
+ instantiated = 1;
+ mutex_unlock(&ui->ui_mutex);
+
+ mutex_lock(&dir_ui->ui_mutex);
+ err = ubifs_jnl_update(c, dir, &dentry->d_name, inode, 1, 0);
+ if (err)
+ goto out_cancel;
+ mutex_unlock(&dir_ui->ui_mutex);
+
+ ubifs_release_budget(c, &req);
+
+ return 0;
+
+out_cancel:
+ mutex_unlock(&dir_ui->ui_mutex);
+out_inode:
+ make_bad_inode(inode);
+ if (!instantiated)
+ iput(inode);
+out_budg:
+ ubifs_release_budget(c, &req);
+ if (!instantiated)
+ ubifs_release_budget(c, &ino_req);
+ ubifs_err(c, "cannot create temporary file, error %d", err);
+ return err;
+}
+
/**
* vfs_dent_type - get VFS directory entry type.
* @type: UBIFS directory entry type
@@ -1189,6 +1259,7 @@ const struct inode_operations ubifs_dir_inode_operations
= {
#ifdef CONFIG_UBIFS_ATIME_SUPPORT
.update_time = ubifs_update_time,
#endif
+ .tmpfile = ubifs_tmpfile,
};
const struct file_operations ubifs_dir_operations = {
--
2.5.0
[patch] sched,rt: __always_inline preemptible_lazy()
homer: # nm kernel/sched/core.o|grep preemptible_lazy
00b5 t preemptible_lazy
echo wakeup_rt > current_tracer ==> Welcome to infinity.
Signed-off-bx: Mike Galbraith
---
kernel/sched/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3469,7 +3469,7 @@ static void __sched notrace preempt_sche
* set by a RT task. Oterwise we try to avoid beeing scheduled out as long as
* preempt_lazy_count counter >0.
*/
-static int preemptible_lazy(void)
+static __always_inline int preemptible_lazy(void)
{
if (test_thread_flag(TIF_NEED_RESCHED))
return 1;
[PATCH] ARM: dts: n900: Use linux input defines instead hardcoded constants
This makes DTS structure more readable.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap3-n900.dts | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index e0443cd..85c29f3 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -65,45 +65,45 @@
camera_lens_cover {
label = "Camera Lens Cover";
gpios = <&gpio4 14 GPIO_ACTIVE_LOW>; /* 110 */
- linux,input-type = <5>; /* EV_SW */
- linux,code = <0x09>; /* SW_CAMERA_LENS_COVER */
+ linux,input-type = ;
+ linux,code = ;
wakeup-source;
};
camera_focus {
label = "Camera Focus";
gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; /* 68 */
- linux,code = <0x210>; /* KEY_CAMERA_FOCUS */
+ linux,code = ;
wakeup-source;
};
camera_capture {
label = "Camera Capture";
gpios = <&gpio3 5 GPIO_ACTIVE_LOW>; /* 69 */
- linux,code = <0xd4>; /* KEY_CAMERA */
+ linux,code = ;
wakeup-source;
};
lock_button {
label = "Lock Button";
gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; /* 113 */
- linux,code = <0x98>; /* KEY_SCREENLOCK */
+ linux,code = ;
wakeup-source;
};
keypad_slide {
label = "Keypad Slide";
gpios = <&gpio3 7 GPIO_ACTIVE_LOW>; /* 71 */
- linux,input-type = <5>; /* EV_SW */
- linux,code = <0x0a>; /* SW_KEYPAD_SLIDE */
+ linux,input-type = ;
+ linux,code = ;
wakeup-source;
};
proximity_sensor {
label = "Proximity Sensor";
gpios = <&gpio3 25 GPIO_ACTIVE_HIGH>; /* 89 */
- linux,input-type = <5>; /* EV_SW */
- linux,code = <0x0b>; /* SW_FRONT_PROXIMITY */
+ linux,input-type = ;
+ linux,code = ;
};
};
--
1.7.9.5
Re: [PATCH v6 16/25] perf ui/stdio: Implement hierarchy output mode
On Sun, Feb 21, 2016 at 12:18:56AM +0100, Jiri Olsa wrote:
> On Tue, Feb 16, 2016 at 11:08:34PM +0900, Namhyung Kim wrote:
>
> SNIP
>
> > +static int hist_entry__hierarchy_fprintf(struct hist_entry *he,
> > +struct perf_hpp *hpp,
> > +int nr_sort_key, struct hists *hists,
> > +FILE *fp)
> > +{
> > + const char *sep = symbol_conf.field_sep;
> > + struct perf_hpp_fmt *fmt;
> > + char *buf = hpp->buf;
> > + int ret, printed = 0;
> > + bool first = true;
> > +
> > + if (symbol_conf.exclude_other && !he->parent)
> > + return 0;
> > +
> > + ret = scnprintf(hpp->buf, hpp->size, "%*s", he->depth *
> > HIERARCHY_INDENT, "");
> > + advance_hpp(hpp, ret);
> > +
> > + hists__for_each_format(he->hists, fmt) {
> > + if (perf_hpp__is_sort_entry(fmt) ||
> > perf_hpp__is_dynamic_entry(fmt))
> > + break;
> > +
> > + /*
> > +* If there's no field_sep, we still need
> > +* to display initial ' '.
> > +*/
> > + if (!sep || !first) {
> > + ret = scnprintf(hpp->buf, hpp->size, "%s", sep ?: " ");
> > + advance_hpp(hpp, ret);
> > + } else
> > + first = false;
> > +
> > + if (perf_hpp__use_color() && fmt->color)
> > + ret = fmt->color(fmt, hpp, he);
> > + else
> > + ret = fmt->entry(fmt, hpp, he);
> > +
> > + advance_hpp(hpp, ret);
>
> there's new hist_entry__snprintf_alignment function for
> proper alignment now used in hist_entry__hierarchy_fprintf
>
> you might wat to use it in here as well
Ah missed that, will change.
Btw it seems it's not strictly needed here since the hierarchy mode
makes each column as the last though. But I agree that it's a general
change and can be applied here as well.
Thanks,
Namhyung
[PATCH 2/6] power_supply: isp1704_charger: Add compatible of match for nxp,isp1707
Signed-off-by: Pali Rohár
---
drivers/power/isp1704_charger.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index acaf7cf..4cd6899 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -536,6 +536,7 @@ static int isp1704_charger_remove(struct platform_device
*pdev)
#ifdef CONFIG_OF
static const struct of_device_id omap_isp1704_of_match[] = {
{ .compatible = "nxp,isp1704", },
+ { .compatible = "nxp,isp1707", },
{},
};
MODULE_DEVICE_TABLE(of, omap_isp1704_of_match);
--
1.7.9.5
[PATCH] ubi: Fix out of bounds write in volume update code
ubi_start_leb_change() alloctes too few bytes. ubi_more_leb_change_data() will write up to req->upd_bytes + ubi->min_io_size bytes. Cc: sta...@vger.kernel.org Signed-off-by: Richard Weinberger --- drivers/mtd/ubi/upd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/upd.c b/drivers/mtd/ubi/upd.c index cfeaf0f..b7901ce 100644 --- a/drivers/mtd/ubi/upd.c +++ b/drivers/mtd/ubi/upd.c @@ -193,7 +193,7 @@ int ubi_start_leb_change(struct ubi_device *ubi, struct ubi_volume *vol, vol->changing_leb = 1; vol->ch_lnum = req->lnum; - vol->upd_buf = vmalloc(req->bytes); + vol->upd_buf = vmalloc(ALIGN((int)req->bytes, ubi->min_io_size)); if (!vol->upd_buf) return -ENOMEM; -- 1.8.4.5
Re: [PATCH v6 25/25] perf top: Add --hierarchy option
On Sun, Feb 21, 2016 at 12:19:29AM +0100, Jiri Olsa wrote: > On Tue, Feb 16, 2016 at 11:08:43PM +0900, Namhyung Kim wrote: > > Support hierarchy output for perf-top using --hierarchy option. > > > > Acked-by: Pekka Enberg > > Signed-off-by: Namhyung Kim > > --- > > tools/perf/Documentation/perf-top.txt | 3 +++ > > tools/perf/builtin-top.c | 15 +++ > > 2 files changed, 18 insertions(+) > > > > diff --git a/tools/perf/Documentation/perf-top.txt > > b/tools/perf/Documentation/perf-top.txt > > index b0e60e17db38..19f046f027cd 100644 > > --- a/tools/perf/Documentation/perf-top.txt > > +++ b/tools/perf/Documentation/perf-top.txt > > @@ -233,6 +233,9 @@ Default is to monitor all CPUS. > > --raw-trace:: > > When displaying traceevent output, do not use print fmt or plugins. > > > > +--hierarchy:: > > + Enable hierarchy output. > > + > > INTERACTIVE PROMPTING KEYS > > -- > > > > diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c > > index a75de3940b97..b86b623e8799 100644 > > --- a/tools/perf/builtin-top.c > > +++ b/tools/perf/builtin-top.c > > @@ -1214,6 +1214,8 @@ int cmd_top(int argc, const char **argv, const char > > *prefix __maybe_unused) > > parse_branch_stack), > > OPT_BOOLEAN(0, "raw-trace", &symbol_conf.raw_trace, > > "Show raw trace event output (do not use print fmt or > > plugins)"), > > + OPT_BOOLEAN(0, "hierarchy", &symbol_conf.report_hierarchy, > > + "Show entries in a hierarchy"), > > hum, I'm not getting --children (default) output with hierarchy? > > I can't see this was intentional.. haven't found the reason yet Currently the hierarchy mode disables the children mode. This is for simplicity and I didn't test the combination thoroughly although it would work. Maybe we can remove the restriction later, but I think it'd be better to start with a simple choice. Thanks, Namhyung
Re: [PATCH] ARM: OMAP2+: Fix onenand initialization to avoid filesystem corruption
Hi, On 11.02.2016 02:12, Tony Lindgren wrote: Also.. There's a chance somebody has created a onenand file system with recent mainline kernels that did the reset and disabled ECC. So with Ivaylo's patch fixing that, those may not mount properly any longer. Most likely people just keep their maemo rootfs there though with the MMC being available. I guess this is possible, but what worries me more is that the longer the patch is not pushed, the higher the chance somebody to end-up with broken rootfs. Wouldn't it be better to push it, thus preventing that happening? BTW the differences for N9/50 come from ONENAND_SYS_CFG1_HF bit and ONENAND_SYS_CFG1_BRL_6 vs ONENAND_SYS_CFG1_BRL_4. Both are changed (later in the code) anyway, so I guess it is safe to reset them to default values. Or, maybe the correct fix is to issue RESET command to onenand controller after GPMC reset? RESET command is supposed to put all the bits to their default values. Ivo.
Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17
On Sun, Feb 21, 2016 at 4:04 PM, Ross Green wrote: > On Sat, Feb 20, 2016 at 5:32 PM, Paul E. McKenney > wrote: >> On Sat, Feb 20, 2016 at 03:34:30PM +1100, Ross Green wrote: >>> On Sat, Feb 20, 2016 at 4:33 AM, Paul E. McKenney >>> wrote: >>> > On Thu, Feb 18, 2016 at 08:13:18PM -0800, John Stultz wrote: >>> >> On Thu, Feb 18, 2016 at 7:56 PM, Ross Green wrote: >>> >> > Well a bonus extra! >>> >> > Kept everything running and there was another stall. >>> >> > So i have included the demsg output for perusal. >>> >> > >>> >> > Just to clear things up there is no hotplug involved in this system. >>> >> > It is a standard Pandaboard ES Ti4460 two processor system. >>> >> > I use this for testing as a generic armv7 processor, plus can keep it >>> >> > just running along for testing for a long time. the system has a total >>> >> > of 23-25 process running on average. Mainly standard daemons. There is >>> >> > certainly no heavy processing going on. I run a series of benchmarks >>> >> > that are cpu intensive for the first 20 miinutes after boot and then >>> >> > just leave it idle away. checking every so often to see how it has >>> >> > gone. >>> >> > As mentioned I have observed these stalls going back to 3.17 kernel. >>> >> > It will often take up to a week to record such a stall. I will >>> >> > typically test every new release kernel, so the -rc? series will get >>> >> > around a weeks testing. >>> >> >>> >> Sorry. Kind of hopping in a bit late here. Is this always happening >>> >> with just the pandaboard? Or are you seeing this on different >>> >> machines? >>> >> >>> >> Have you tried enabling CONFIG_DEBUG_TIMEKEEPING just in case >>> >> something is going awry there? >>> > >>> > Excellent point -- timekeeping issues have caused this sort of issue >>> > in the past. >>> > >>> > Ross, on your next test, could you please enable CONFIG_DEBUG_TIMEKEEPING >>> > as John suggests? >>> > >>> > Thanx, Paul >>> > >>> As John has suggested have already enabled CONFIG_DEBUG_TIMEKEEPING. >>> >>> So far just on 1 day running. >>> >>> Sigh...!! Nothing to report as yet, only one day on the clock. >>> Its like watching grass grow! >> >> I hear you! Though I was thinking in terms of watching paint dry... >> >> Thanx, Paul >> > Yes, > > but with paint drying there is an end point! > Grass just keeps on growing ... > > More like the children in the back of the car ... > Are we there yet? ... > > Well still nothing .. to report. I have just built a 4.5-rc5, but will > wait till I get some outcome from the previous test. That can't be too > much longer! > > In hope, > > Ross Green Patience little ones ... Well after 2 days plus running pulled another stall. This is with 4.5-rc4 and CONFIG_DEBUG_TIMEKEEPING set. Can't see anything related to the TIMEKEEPING. Anyway here is the dmesg output for people to look at. Paul, I was going to move onto 4.5-rc5 kernel, is there something else that you want me to test with that, Anyone else have any suggestions or ideas? Regards, Ross Green dmesg-4.5-rc4-3 Description: Binary data
Re: [PATCH v1 2/4] block: check virt boundary in bio_will_gap()
Looks fine, Reviewed-by: Sagi Grimberg
Re: [PATCH 2/2] bmips: add device tree example for BCM6358
El 20/01/2016 a las 17:59, Rob Herring escribió:
On Sun, Jan 17, 2016 at 12:28:21PM +0100, Álvaro Fernández Rojas wrote:
This adds a device tree example for SFR Neufbox4 (Sercomm version), which
also serves as a real example for brcm,bcm6358-leds.
Signed-off-by: Álvaro Fernández Rojas
[...]
diff --git a/arch/mips/boot/dts/brcm/bcm6358.dtsi
b/arch/mips/boot/dts/brcm/bcm6358.dtsi
new file mode 100644
index 000..b2d11da
--- /dev/null
+++ b/arch/mips/boot/dts/brcm/bcm6358.dtsi
@@ -0,0 +1,111 @@
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "brcm,bcm6358";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mips-hpt-frequency = <15000>;
+
+ cpu@0 {
+ compatible = "brcm,bmips4350";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "brcm,bmips4350";
+ device_type = "cpu";
+ reg = <1>;
+ };
+ };
+
+ clocks {
+ periph_clk: periph_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ };
+ };
+
+ aliases {
+ leds0 = &leds0;
Why do we need alias for LEDs?
Okay, I will remove this, but you should know it was accepted for
BCM6328 and BCM6368 too:
http://git.linux-mips.org/cgit/sjhill/linux-sjhill.git/commit/arch/mips/boot/dts/brcm?h=mips-for-linux-next&id=db66dbbbfd8ded204a97d090357aff582968fcf5
http://git.linux-mips.org/cgit/sjhill/linux-sjhill.git/commit/arch/mips/boot/dts/brcm?h=mips-for-linux-next&id=70ce14bfc9fdb9b6af84ac492e9d3311551618a5
+ uart0 = &uart0;
+ uart1 = &uart1;
+ };
[...]
diff --git a/arch/mips/boot/dts/brcm/bcm96358nb4ser.dts
b/arch/mips/boot/dts/brcm/bcm96358nb4ser.dts
new file mode 100644
index 000..ca95084
--- /dev/null
+++ b/arch/mips/boot/dts/brcm/bcm96358nb4ser.dts
@@ -0,0 +1,47 @@
+/dts-v1/;
+
+/include/ "bcm6358.dtsi"
+
+/ {
+ compatible = "sfr,nb4-ser", "brcm,bcm6358";
+ model = "SFR Neufbox 4 (Sercomm)";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x 0x0200>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ stdout-path = &uart0;
You shouldn't need both here. Just stdout-path.
Okay, I will use stdout-path only, but once again you should know that
both are used on every bmips board:
https://github.com/torvalds/linux/tree/master/arch/mips/boot/dts/brcm
https://github.com/torvalds/linux/blob/master/arch/mips/boot/dts/brcm/bcm93384wvg.dts#L9
...
https://github.com/torvalds/linux/blob/master/arch/mips/boot/dts/brcm/bcm9ejtagprb.dts#L14
Rob
Álvaro.
[PATCH 0/6] Small fixes for Nokia N900 power supply drivers
This patch series add debug error output for isp1704 driver and fix module aliases for power supply drivers uses on Nokia N900. Pali Rohár (6): power_supply: isp1704_charger: Error messages when probe fail power_supply: isp1704_charger: Add compatible of match for nxp,isp1707 power_supply: bq2415x_charger: Do not add acpi modalias when CONFIG_ACPI is not enabled power_supply: bq2415x_charger: Add of modalias and match table when CONFIG_OF is enabled power_supply: bq27xxx_battery: Add of modalias and match table when CONFIG_OF is enabled ARM: dts: n900: Rename isp1704 to isp1707 to match correct name arch/arm/boot/dts/omap3-n900.dts|6 +++--- drivers/power/bq2415x_charger.c | 22 ++ drivers/power/bq27xxx_battery.c | 12 drivers/power/bq27xxx_battery_i2c.c | 24 drivers/power/isp1704_charger.c | 19 +++ 5 files changed, 76 insertions(+), 7 deletions(-) -- 1.7.9.5
Re: [PATCH v1 1/4] block: bio: introduce helpers to get the 1st and last bvec
Looks fine, Reviewed-by: Sagi Grimberg
Re: [PATCH 3/6] power_supply: bq2415x_charger: Do not add acpi modalias when CONFIG_ACPI is not enabled
On Sun 2016-02-21 12:28:20, Pali Rohár wrote:
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> @@ -1759,6 +1759,7 @@ static const struct i2c_device_id
> bq2415x_i2c_id_table[] = {
> };
> MODULE_DEVICE_TABLE(i2c, bq2415x_i2c_id_table);
>
> +#ifdef CONFIG_ACPI
> static const struct acpi_device_id bq2415x_i2c_acpi_match[] = {
> { "BQ2415X", BQUNKNOWN },
> { "BQ241500", BQ24150 },
> @@ -1776,6 +1777,7 @@ static const struct acpi_device_id
> bq2415x_i2c_acpi_match[] = {
> {},
> };
> MODULE_DEVICE_TABLE(acpi, bq2415x_i2c_acpi_match);
> +#endif
>
> static struct i2c_driver bq2415x_driver = {
> .driver = {
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH 6/6] ARM: dts: n900: Rename isp1704 to isp1707 to match correct name
This change does not break existing userspace or Maemo software because
isp1704_charger.c always export power supply device under isp1704 name.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap3-n900.dts |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 82df643..e0443cd 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -107,8 +107,8 @@
};
};
- isp1704: isp1704 {
- compatible = "nxp,isp1704";
+ isp1707: isp1707 {
+ compatible = "nxp,isp1707";
nxp,enable-gpio = <&gpio3 3 GPIO_ACTIVE_HIGH>;
usb-phy = <&usb2_phy>;
};
@@ -735,7 +735,7 @@
ti,termination-current = <100>;
ti,resistor-sense = <68>;
- ti,usb-charger-detection = <&isp1704>;
+ ti,usb-charger-detection = <&isp1707>;
};
};
--
1.7.9.5
Re: Nokia N900: musb is in wrong state after boot
On Tuesday 26 January 2016 18:26:32 Tony Lindgren wrote: > * Pali Rohár [160126 06:35]: > > On Thursday 21 January 2016 12:30:13 Tony Lindgren wrote: > > > * joerg Reisenweber [160121 11:35]: > > > > On Thu 21 January 2016 11:21:13 Tony Lindgren wrote: > > > > > Do you have some pointer > > > > > to the "certain resistor value on ID to GND" spec? Is it > > > > > maybe part of the carkit related parts of the USB spec? > > > > > > > > ""Three additional ID pin states are defined[4] at the nominal > > > > resistance values of 124 kΩ, 68 kΩ, and 36.5 kΩ, with respect > > > > to the ground pin. These permit the device to work with USB > > > > Accessory Charger Adapters that allows the OTG device to be > > > > attached to both a charger and another device simultaneously. > > > > [6]"" > > > > https://en.wikipedia.org/wiki/USB_On-The-Go#OTG_micro_plugs > > > > > > OK thanks. So it's the "accessory charger" part of the > > > battery charging specification 1.1. > > > > So, Tony, do you have some idea what needs to be changed and how to > > fix peripheral mode after boot on Nokia N900? > > No, I'm waiting to hear an educated guess from Felipe on this one. PING! Still no answer. Felipe changed email address. > > First I would like to have fully working peripheral mode on Nokia > > N900 and then we can try to hack host mode (if possible). > > > > But peripheral mode is a must due to development, because it > > provides usb network or usb tty. > > Totally. > > Regards, > > Tony -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/6] power_supply: isp1704_charger: Error messages when probe fail
Hi! > This patch adds more detailed error messages when probe function > fail. ...fails. > It is useful for debbuging why driver refuse to register charger device. ...why the driver refuses to register... Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[GIT PULL] hwmon fixes for v4.5-rc6
Hi Linus, Please pull hwmon fixes for Linux v4.5-rc6 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-v4.5-rc6 Thanks, Guenter -- The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865: Linux 4.5-rc4 (2016-02-14 13:05:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-linus-v4.5-rc6 for you to fetch changes up to 000e0949148382c4962489593a2f05504c2a6771: hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook (2016-02-19 17:14:25 -0800) Two fixes headed for stable: Remove an un-necessary speed_index lookup for thermal hook in the gpio-fan driver. The unnecessary speed lookup can hog the system. Handle negative conversion values correctly in the ads1015 driver. Nishanth Menon (1): hwmon: (gpio-fan) Remove un-necessary speed_index lookup for thermal hook Peter Rosin (1): hwmon: (ads1015) Handle negative conversion values correctly drivers/hwmon/ads1015.c | 2 +- drivers/hwmon/gpio-fan.c | 7 +-- 2 files changed, 2 insertions(+), 7 deletions(-)
[PATCH] Staging: rdma: hfi1: verbs_mcast: fixed a brace coding style issue
Fixed a coding style issue.
Signed-off-by: Jannik Becher
---
drivers/staging/rdma/hfi1/verbs_mcast.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rdma/hfi1/verbs_mcast.c
b/drivers/staging/rdma/hfi1/verbs_mcast.c
index afc6b4c..c45d4b1 100644
--- a/drivers/staging/rdma/hfi1/verbs_mcast.c
+++ b/drivers/staging/rdma/hfi1/verbs_mcast.c
@@ -140,11 +140,11 @@ struct hfi1_mcast *hfi1_mcast_find(struct hfi1_ibport
*ibp, union ib_gid *mgid)
ret = memcmp(mgid->raw, mcast->mgid.raw,
sizeof(union ib_gid));
- if (ret < 0)
+ if (ret < 0) {
n = n->rb_left;
- else if (ret > 0)
+ } else if (ret > 0) {
n = n->rb_right;
- else {
+ } else {
atomic_inc(&mcast->refcount);
spin_unlock_irqrestore(&ibp->lock, flags);
goto bail;
--
2.5.0
[PATCH 4/5] perf tools: Fix alignment on some sort keys
The srcline, srcfile and trace sort keys can have long entries. With
commit 89fee7094323 ("perf hists: Do column alignment on the format
iterator"), it now aligns output with hist_entry__snprintf_alignment().
So each (possibly long) sort entries don't need to do it themselves.
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 6808d73164b5..1d2b85c808d0 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -325,7 +325,7 @@ static int hist_entry__srcline_snprintf(struct hist_entry
*he, char *bf,
he->ms.sym, true);
}
}
- return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcline);
+ return repsep_snprintf(bf, size, "%-.*s", width, he->srcline);
}
struct sort_entry sort_srcline = {
@@ -384,7 +384,7 @@ static int hist_entry__srcfile_snprintf(struct hist_entry
*he, char *bf,
else
he->srcfile = get_srcfile(he);
}
- return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcfile);
+ return repsep_snprintf(bf, size, "%-.*s", width, he->srcfile);
}
struct sort_entry sort_srcfile = {
@@ -514,11 +514,11 @@ static int hist_entry__trace_snprintf(struct hist_entry
*he, char *bf,
evsel = hists_to_evsel(he->hists);
if (evsel->attr.type != PERF_TYPE_TRACEPOINT)
- return scnprintf(bf, size, "%-*.*s", width, width, "N/A");
+ return scnprintf(bf, size, "%-.*s", width, "N/A");
if (he->trace_output == NULL)
he->trace_output = get_trace_output(he);
- return repsep_snprintf(bf, size, "%-*.*s", width, width,
he->trace_output);
+ return repsep_snprintf(bf, size, "%-.*s", width, he->trace_output);
}
struct sort_entry sort_trace = {
--
2.7.1
[PATCH 2/5] perf tools: Fix segfault on dynamic entries
The dynamic entry is created for each tracepoint event. When it sets up
the sort key, it checks with existing keys using ->equal() callback.
But it missed to set the ->equal for dynamic entries. The following
segfault was due to the missing ->equal() callback.
(gdb) bt
#0 0x00140003 in ?? ()
#1 0x00537769 in fmt_equal (b=0x2106980, a=0x21067a0) at
ui/hist.c:548
#2 perf_hpp__setup_output_field (list=0x8c6d80 ) at
ui/hist.c:560
#3 0x004e927e in setup_sorting (evlist=) at
util/sort.c:2642
#4 0x0043cf50 in cmd_report (argc=, argv=, prefix=)
at builtin-report.c:932
#5 0x004865a1 in run_builtin (p=p@entry=0x8bbce0 ,
argc=argc@entry=7,
argv=argv@entry=0x7ffd24d56ce0) at perf.c:390
#6 0x0042dc1f in handle_internal_command (argv=0x7ffd24d56ce0,
argc=7) at perf.c:451
#7 run_argv (argv=0x7ffd24d56a70, argcp=0x7ffd24d56a7c) at perf.c:495
#8 main (argc=7, argv=0x7ffd24d56ce0) at perf.c:620
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index de715756f281..7daea71691df 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -1835,6 +1835,20 @@ bool perf_hpp__is_dynamic_entry(struct perf_hpp_fmt *fmt)
return fmt->cmp == __sort__hde_cmp;
}
+static bool __sort__hde_equal(struct perf_hpp_fmt *a, struct perf_hpp_fmt *b)
+{
+ struct hpp_dynamic_entry *hde_a;
+ struct hpp_dynamic_entry *hde_b;
+
+ if (!perf_hpp__is_dynamic_entry(a) || !perf_hpp__is_dynamic_entry(b))
+ return false;
+
+ hde_a = container_of(a, struct hpp_dynamic_entry, hpp);
+ hde_b = container_of(b, struct hpp_dynamic_entry, hpp);
+
+ return hde_a->field == hde_b->field;
+}
+
static void hde_free(struct perf_hpp_fmt *fmt)
{
struct hpp_dynamic_entry *hde;
@@ -1867,6 +1881,7 @@ __alloc_dynamic_entry(struct perf_evsel *evsel, struct
format_field *field)
hde->hpp.cmp = __sort__hde_cmp;
hde->hpp.collapse = __sort__hde_cmp;
hde->hpp.sort = __sort__hde_cmp;
+ hde->hpp.equal = __sort__hde_equal;
hde->hpp.free = hde_free;
INIT_LIST_HEAD(&hde->hpp.list);
--
2.7.1
Re: rcu_preempt self-detected stall on CPU from 4.5-rc3, since 3.17
On Sat, Feb 20, 2016 at 5:32 PM, Paul E. McKenney wrote: > On Sat, Feb 20, 2016 at 03:34:30PM +1100, Ross Green wrote: >> On Sat, Feb 20, 2016 at 4:33 AM, Paul E. McKenney >> wrote: >> > On Thu, Feb 18, 2016 at 08:13:18PM -0800, John Stultz wrote: >> >> On Thu, Feb 18, 2016 at 7:56 PM, Ross Green wrote: >> >> > Well a bonus extra! >> >> > Kept everything running and there was another stall. >> >> > So i have included the demsg output for perusal. >> >> > >> >> > Just to clear things up there is no hotplug involved in this system. >> >> > It is a standard Pandaboard ES Ti4460 two processor system. >> >> > I use this for testing as a generic armv7 processor, plus can keep it >> >> > just running along for testing for a long time. the system has a total >> >> > of 23-25 process running on average. Mainly standard daemons. There is >> >> > certainly no heavy processing going on. I run a series of benchmarks >> >> > that are cpu intensive for the first 20 miinutes after boot and then >> >> > just leave it idle away. checking every so often to see how it has >> >> > gone. >> >> > As mentioned I have observed these stalls going back to 3.17 kernel. >> >> > It will often take up to a week to record such a stall. I will >> >> > typically test every new release kernel, so the -rc? series will get >> >> > around a weeks testing. >> >> >> >> Sorry. Kind of hopping in a bit late here. Is this always happening >> >> with just the pandaboard? Or are you seeing this on different >> >> machines? >> >> >> >> Have you tried enabling CONFIG_DEBUG_TIMEKEEPING just in case >> >> something is going awry there? >> > >> > Excellent point -- timekeeping issues have caused this sort of issue >> > in the past. >> > >> > Ross, on your next test, could you please enable CONFIG_DEBUG_TIMEKEEPING >> > as John suggests? >> > >> > Thanx, Paul >> > >> As John has suggested have already enabled CONFIG_DEBUG_TIMEKEEPING. >> >> So far just on 1 day running. >> >> Sigh...!! Nothing to report as yet, only one day on the clock. >> Its like watching grass grow! > > I hear you! Though I was thinking in terms of watching paint dry... > > Thanx, Paul > Yes, but with paint drying there is an end point! Grass just keeps on growing ... More like the children in the back of the car ... Are we there yet? ... Well still nothing .. to report. I have just built a 4.5-rc5, but will wait till I get some outcome from the previous test. That can't be too much longer! In hope, Ross Green
[PATCH 5/5] perf tools: Fix column width setting on 'trace' sort key
It missed to update column length of the 'trace' sort key in the hists__calc_col_len() so it might truncate the output. It calculated the column length in the ->cmp() callback originally but it doesn't guarantee it's called always. Signed-off-by: Namhyung Kim --- tools/perf/util/hist.c | 3 +++ tools/perf/util/sort.c | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c index 827c6cbcd05d..017eb5c42c37 100644 --- a/tools/perf/util/hist.c +++ b/tools/perf/util/hist.c @@ -179,6 +179,9 @@ void hists__calc_col_len(struct hists *hists, struct hist_entry *h) if (h->transaction) hists__new_col_len(hists, HISTC_TRANSACTION, hist_entry__transaction_len()); + + if (h->trace_output) + hists__new_col_len(hists, HISTC_TRACE, strlen(h->trace_output)); } void hists__output_recalc_col_len(struct hists *hists, int max_rows) diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c index 1d2b85c808d0..ea05497cfee9 100644 --- a/tools/perf/util/sort.c +++ b/tools/perf/util/sort.c @@ -501,9 +501,6 @@ sort__trace_cmp(struct hist_entry *left, struct hist_entry *right) if (right->trace_output == NULL) right->trace_output = get_trace_output(right); - hists__new_col_len(left->hists, HISTC_TRACE, strlen(left->trace_output)); - hists__new_col_len(right->hists, HISTC_TRACE, strlen(right->trace_output)); - return strcmp(right->trace_output, left->trace_output); } -- 2.7.1
Re: [PATCHv6 1/3] rdmacg: Added rdma cgroup controller
CONFIG_CGROUP_RDMA On Sun, Feb 21, 2016 at 7:15 PM, Leon Romanovsky wrote: > On Sun, Feb 21, 2016 at 05:03:05PM +0530, Parav Pandit wrote: >> On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote: >> > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote: >> > Can you place this ifdef before declaring struct rdma_cgroup? >> Yes. I missed out this cleanup. Done locally now. > > Great, additional thing which spotted my attention was related to > declaring and using the new cgroups functions. There are number of > places where you protected the calls by specific ifdefs in the > IB/core c-files and not in h-files as it is usually done. > ib_device_register_rdmacg, ib_device_unregister_rdmacg are the only two functions called from IB/core as its tied to functionality. They can also be implemented as NULL call when CONFIG_CGROUP_RDMA is undefined. (Similar to ib_rdmacg_try_charge and others). I didn't do because occurrence of call of register and unregister is limited to single file and only twice compare to charge/uncharge functions. Either way is fine with me, I can make the changes which you described. Let me know. >> >> > Thanks
Re: [PATCH] pinctrl: sunxi: Add missing H3 R_PIO binding documentation
On Thu, Feb 18, 2016 at 11:49 AM, Krzysztof Adamski wrote:
> allwinner,sun8i-h3-r-pinctrl was added by
> commit ba83a11104ae ("pinctrl: sunxi: Add H3 R_PIO controller support")
> but the patch was missing proper binding documentation. This patch fixes
> this issue.
>
> Signed-off-by: Krzysztof Adamski
Acked-by: Chen-Yu Tsai
[PATCH 1/6] power_supply: isp1704_charger: Error messages when probe fail
This patch adds more detailed error messages when probe function fail.
It is useful for debbuging why driver refuse to register charger device.
Signed-off-by: Pali Rohár
---
drivers/power/isp1704_charger.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index 46a292a..acaf7cf 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -411,8 +411,10 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
if (np) {
int gpio = of_get_named_gpio(np, "nxp,enable-gpio", 0);
- if (gpio < 0)
+ if (gpio < 0) {
+ dev_err(&pdev->dev, "missing DT GPIO
nxp,enable-gpio\n");
return gpio;
+ }
pdata = devm_kzalloc(&pdev->dev,
sizeof(struct isp1704_charger_data), GFP_KERNEL);
@@ -422,8 +424,10 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
ret = devm_gpio_request_one(&pdev->dev, pdata->enable_gpio,
GPIOF_OUT_INIT_HIGH, "isp1704_reset");
- if (ret)
+ if (ret) {
+ dev_err(&pdev->dev, "gpio request failed\n");
goto fail0;
+ }
}
if (!pdata) {
@@ -443,6 +447,7 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
if (IS_ERR(isp->phy)) {
ret = PTR_ERR(isp->phy);
+ dev_err(&pdev->dev, "usb_get_phy failed\n");
goto fail0;
}
@@ -452,8 +457,10 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
isp1704_charger_set_power(isp, 1);
ret = isp1704_test_ulpi(isp);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&pdev->dev, "isp1704_test_ulpi failed\n");
goto fail1;
+ }
isp->psy_desc.name = "isp1704";
isp->psy_desc.type = POWER_SUPPLY_TYPE_USB;
@@ -466,6 +473,7 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
isp->psy = power_supply_register(isp->dev, &isp->psy_desc, &psy_cfg);
if (IS_ERR(isp->psy)) {
ret = PTR_ERR(isp->psy);
+ dev_err(&pdev->dev, "power_supply_register failed\n");
goto fail1;
}
@@ -478,8 +486,10 @@ static int isp1704_charger_probe(struct platform_device
*pdev)
isp->nb.notifier_call = isp1704_notifier_call;
ret = usb_register_notifier(isp->phy, &isp->nb);
- if (ret)
+ if (ret) {
+ dev_err(&pdev->dev, "usb_register_notifier failed\n");
goto fail2;
+ }
dev_info(isp->dev, "registered with product id %s\n", isp->model);
--
1.7.9.5
[PATCH 3/5] perf tools: Update srcline/file if needed
Normally the hist entry's srcline and/or srcfile is set during sorting.
However sometime it's possible to a hist entry's srcline is not set yet
after the sorting. This is because the entry is so unique and other
sort keys already make it distinct. Then the srcline/file sort didn't
have a chance to be called during the sorting. In that case it has NULL
srcline/srcfile field and shows nothing.
Before:
$ perf report -s comm,sym,srcline
...
Overhead Command Symbol
-
34.42% swapper [k] intel_idle intel_idle.c:0
2.44% perf [.] __poll_nocancel (null)
1.70% gnome-shell [k] fw_domains_get (null)
1.04% Xorg [k] sock_poll (null)
After:
34.42% swapper [k] intel_idle intel_idle.c:0
2.44% perf [.] __poll_nocancel .:0
1.70% gnome-shell [k] fw_domains_get fw_domains_get+42
1.04% Xorg [k] sock_poll socket.c:0
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 16
1 file changed, 16 insertions(+)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 7daea71691df..6808d73164b5 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -315,6 +315,16 @@ sort__srcline_cmp(struct hist_entry *left, struct
hist_entry *right)
static int hist_entry__srcline_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
+ if (!he->srcline) {
+ if (!he->ms.map)
+ he->srcline = SRCLINE_UNKNOWN;
+ else {
+ struct map *map = he->ms.map;
+ he->srcline = get_srcline(map->dso,
+ map__rip_2objdump(map, he->ip),
+ he->ms.sym, true);
+ }
+ }
return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcline);
}
@@ -368,6 +378,12 @@ sort__srcfile_cmp(struct hist_entry *left, struct
hist_entry *right)
static int hist_entry__srcfile_snprintf(struct hist_entry *he, char *bf,
size_t size, unsigned int width)
{
+ if (!he->srcfile) {
+ if (!he->ms.map)
+ he->srcfile = no_srcfile;
+ else
+ he->srcfile = get_srcfile(he);
+ }
return repsep_snprintf(bf, size, "%-*.*s", width, width, he->srcfile);
}
--
2.7.1
Re: [PATCHv6 1/3] rdmacg: Added rdma cgroup controller
On Sun, Feb 21, 2016 at 1:13 PM, Leon Romanovsky wrote: > On Sat, Feb 20, 2016 at 04:30:04PM +0530, Parav Pandit wrote: > Can you place this ifdef before declaring struct rdma_cgroup? Yes. I missed out this cleanup. Done locally now. > Thanks
[PATCH] cpumask: remove incorrect information from comment
Since commit cdfdef75e795f ("cpumask: only allocate nr_cpumask_bits."),
this comment above cpumask_size() is no longer relevant.
Signed-off-by: Eric Biggers
---
include/linux/cpumask.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index fc14275..40cee6b 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -607,8 +607,6 @@ static inline int cpulist_parse(const char *buf, struct
cpumask *dstp)
/**
* cpumask_size - size to allocate for a 'struct cpumask' in bytes
- *
- * This will eventually be a runtime variable, depending on nr_cpu_ids.
*/
static inline size_t cpumask_size(void)
{
--
2.7.1
[PATCH 5/6] power_supply: bq27xxx_battery: Add of modalias and match table when CONFIG_OF is enabled
Signed-off-by: Pali Rohár
---
drivers/power/bq27xxx_battery.c | 12
drivers/power/bq27xxx_battery_i2c.c | 24
2 files changed, 36 insertions(+)
diff --git a/drivers/power/bq27xxx_battery.c b/drivers/power/bq27xxx_battery.c
index 6b027a4..45f6ebf 100644
--- a/drivers/power/bq27xxx_battery.c
+++ b/drivers/power/bq27xxx_battery.c
@@ -46,6 +46,7 @@
#include
#include
#include
+#include
#include
@@ -1090,16 +1091,27 @@ static const struct platform_device_id
bq27xxx_battery_platform_id_table[] = {
};
MODULE_DEVICE_TABLE(platform, bq27xxx_battery_platform_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id bq27xxx_battery_platform_of_match_table[] = {
+ { .compatible = "ti,bq27000" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bq27xxx_battery_platform_of_match_table);
+#endif
+
static struct platform_driver bq27xxx_battery_platform_driver = {
.probe = bq27xxx_battery_platform_probe,
.remove = bq27xxx_battery_platform_remove,
.driver = {
.name = "bq27000-battery",
+ .of_match_table =
of_match_ptr(bq27xxx_battery_platform_of_match_table),
},
.id_table = bq27xxx_battery_platform_id_table,
};
module_platform_driver(bq27xxx_battery_platform_driver);
+MODULE_ALIAS("platform:bq27000-battery");
+
MODULE_AUTHOR("Rodolfo Giometti ");
MODULE_DESCRIPTION("BQ27xxx battery monitor driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/power/bq27xxx_battery_i2c.c
b/drivers/power/bq27xxx_battery_i2c.c
index 9429e66..b810e08 100644
--- a/drivers/power/bq27xxx_battery_i2c.c
+++ b/drivers/power/bq27xxx_battery_i2c.c
@@ -135,9 +135,33 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[] =
{
};
MODULE_DEVICE_TABLE(i2c, bq27xxx_i2c_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id bq27xxx_battery_i2c_of_match_table[] = {
+ { .compatible = "ti,bq27200" },
+ { .compatible = "ti,bq27210" },
+ { .compatible = "ti,bq27500" },
+ { .compatible = "ti,bq27510" },
+ { .compatible = "ti,bq27520" },
+ { .compatible = "ti,bq27530" },
+ { .compatible = "ti,bq27531" },
+ { .compatible = "ti,bq27541" },
+ { .compatible = "ti,bq27542" },
+ { .compatible = "ti,bq27546" },
+ { .compatible = "ti,bq27742" },
+ { .compatible = "ti,bq27545" },
+ { .compatible = "ti,bq27421" },
+ { .compatible = "ti,bq27425" },
+ { .compatible = "ti,bq27441" },
+ { .compatible = "ti,bq27621" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
+#endif
+
static struct i2c_driver bq27xxx_battery_i2c_driver = {
.driver = {
.name = "bq27xxx-battery",
+ .of_match_table =
of_match_ptr(bq27xxx_battery_i2c_of_match_table),
},
.probe = bq27xxx_battery_i2c_probe,
.remove = bq27xxx_battery_i2c_remove,
--
1.7.9.5
Re: [Nbd] [PATCH] nbd: ratelimit error messages from disconnected devices
Hi,
On Tuesday 16 February 2016 14:33:01 Dmitry Monakhov wrote:
> ndb can be explicitly disconnected via NBD_DISCONNECT while
> active user still exists this result in massive spam to logs.
> Let's ratelimits such messages.
>
> Signed-off-by: Dmitry Monakhov
> ---
> drivers/block/nbd.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index e4c5cc1..2dbe840 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -175,7 +175,7 @@ static int sock_xmit(struct nbd_device *nbd, int send,
> void *buf, int size,
> unsigned long pflags = current->flags;
>
> if (unlikely(!sock)) {
> - dev_err(disk_to_dev(nbd->disk),
> + dev_err_ratelimited(disk_to_dev(nbd->disk),
> "Attempted %s on closed socket in sock_xmit\n",
Please indent to the first opening bracket.
> (send ? "send" : "recv"));
> return -EINVAL;
> @@ -509,7 +509,7 @@ static void nbd_handle_req(struct nbd_device *nbd, struct
> request *req)
> mutex_lock(&nbd->tx_lock);
> if (unlikely(!nbd->sock)) {
> mutex_unlock(&nbd->tx_lock);
> - dev_err(disk_to_dev(nbd->disk),
> + dev_err_ratelimited(disk_to_dev(nbd->disk),
> "Attempted send on closed socket\n");
> goto error_out;
> }
> @@ -618,7 +618,7 @@ static void nbd_request_handler(struct request_queue *q)
> req, req->cmd_type);
>
> if (unlikely(!nbd->sock)) {
> - dev_err(disk_to_dev(nbd->disk),
> + dev_err_ratelimited(disk_to_dev(nbd->disk),
> "Attempted send on closed socket\n");
This conflicts with a patch already applied fixing the same.
Please rebase onto nbd master [1]
Best Regards,
Markus
[1]
http://git.pengutronix.de/?p=mpa/linux-nbd.git;a=shortlog;h=refs/heads/master
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v1 0/4] block: fix bio_will_gap()
Hi Guys, The bio passed to bio_will_gap() may be fast cloned from upper layer(dm, md, bcache, fs, ...), or from bio splitting in block core. Unfortunately bio_will_gap() just figures out the last bvec via 'bi_io_vec[prev->bi_vcnt - 1]' directly, and this way is obviously wrong in case of fast-cloned bio. It is observed that lots of BIOs are still merged even if the virt boundary limit is violated by the merge, and the issue was reported from Sagi Grimberg. This patch introduces two helpers for getting the first and last bvec of one bio and applys them to fix the issue. Sagi tested the last patchset and confirmed the fix. V1: - get bvec directly for non-cloned bio - implement bio_get_last_bvec() with single bio_advance_iter(), and avoid to use bio_for_each_segment() which looks a bit inefficient - avoid to double check queue_virt_boundary() in bio_will_gap() Thanks Ming, Jens, can this make the next 4.5-rc since this regression was detected in 4.5? Thanks, Sagi.
