Re: [PATCH 2/2] cpuidle: fix sysfs output for power_usage
On Monday, December 17, 2012 09:38:15 AM Sivaram Nair wrote: > On Sat, Dec 15, 2012 at 01:03:02AM +0100, Rafael J. Wysocki wrote: > > On Friday, December 14, 2012 03:17:37 PM Sivaram Nair wrote: > > > cpuidle_state->power_usage is signed; so change the corresponding sysfs > > > ops to output signed value instead of unsigned. > > > > What's actually wrong with printing it as an unsigned int? > > power_usage could have negative values (for example cpuidle/driver.c > inits this value to -1, -2 etc. when drv->power_specified is not set) and > these shows up badly in the sysfs output. Does "badly" mean "as big positive numbers"? Should we actually print them at all in those case? Perhaps it'll be better to make the file appear empty then? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI: Simplify namespace scanning for devices
On Sunday, December 16, 2012 11:00:04 PM Yinghai Lu wrote: > On Sun, Dec 16, 2012 at 2:31 PM, Rafael J. Wysocki wrote: > > On Sunday, December 16, 2012 09:36:49 AM Yinghai Lu wrote: > > There you go: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > > acpi-scan-temp > > > >> I'd like to rebase for-pci-root-bus-hotplug patches, so what should be > >> base? > > > rebase all pci patches (without four patches about drivers_autoprobe > and remove acpi_pci_root_start) > on top your branch. > > root bus hotplug seems work well without problem. > > Thanks a lot. Great, thanks for testing. :-) Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PCI: Set root bridge ACPI handle in advance
On Sunday, December 16, 2012 09:27:49 PM Yinghai Lu wrote: > On Sun, Dec 16, 2012 at 2:25 PM, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki > > > > The ACPI handles of PCI root bridges need to be known to > > acpi_bind_one(), so that it can create the appropriate > > "firmware_node" and "physical_node" files for them, but currently > > the way it gets to know those handles is not exactly straightforward > > (to put it lightly). > > > > This is how it works, roughly: > > > > 1. acpi_bus_scan() finds the handle of a PCI root bridge, > > creates a struct acpi_device object for it and passes that > > object to acpi_pci_root_add(). > > > > 2. acpi_pci_root_add() creates a struct acpi_pci_root object, > > populates its "device" field with its argument's address > > (device->handle is the ACPI handle found in step 1). > > > > 3. The struct acpi_pci_root object created in step 2 is passed > > to pci_acpi_scan_root() and used to get resources that are > > passed to pci_create_root_bus(). > > > > 4. pci_create_root_bus() creates a struct pci_host_bridge object > > and passes its "dev" member to device_register(). > > > > 5. platform_notify(), which for systems with ACPI is set to > > acpi_platform_notify(), is called. > > > > So far, so good. Now it starts to be "interesting". > > > > 6. acpi_find_bridge_device() is used to find the ACPI handle of > > the given device (which is the PCI root bridge) and executes > > acpi_pci_find_root_bridge(), among other things, for the > > given device object. > > > > 7. acpi_pci_find_root_bridge() uses the name (sic!) of the given > > device object to extract the segment and bus numbers of the PCI > > root bridge and passes them to acpi_get_pci_rootbridge_handle(). > > > > 8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI > > root bridges and finds the one that matches the given segment > > and bus numbers. Its handle is then used to initialize the > > ACPI handle of the PCI root bridge's device object by > > acpi_bind_one(). However, this is *exactly* the ACPI handle we > > started with in step 1. > > > > Needless to say, this is quite embarassing, but it may be avoided > > thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be > > initialized in advance), which makes it possible to initialize the > > ACPI handle of a device before passing it to device_register(). > > Namely, if pci_acpi_scan_root() could easily pass the root bridge's > > ACPI handle to pci_create_root_bus(), the latter could set the ACPI > > handle in its struct pci_host_bridge object's "dev" member before > > passing it to device_register() and steps 6-8 above wouldn't be > > necessary any more. > > > > To make that happen I decided to repurpose the 4th argument of > > pci_create_root_bus(), because that allowed me to avoid defining > > additional callbacks or similar things and didn't seem to impact > > architectures without ACPI substantially. > > > > Only x86 and ia64 are affected directly, there should be no > > functional changes resulting from this on other architectures. > > that is good one to avoid that find_root_bridge... > > > > > Signed-off-by: Rafael J. Wysocki > > --- > > > > Should apply to the current Linus' tree, boots correctly on x86(-64). > > > > --- > > arch/ia64/pci/pci.c |5 - > > arch/powerpc/kernel/pci-common.c |3 ++- > > arch/sparc/kernel/pci.c |3 ++- > > arch/x86/pci/acpi.c |5 - > > drivers/acpi/pci_root.c | 18 -- > > drivers/pci/pci-acpi.c | 19 --- > > drivers/pci/probe.c | 16 +++- > > include/acpi/acpi_bus.h |1 - > > include/linux/pci.h |9 - > > 9 files changed, 31 insertions(+), 48 deletions(-) > > you need to update other arch for pci_create_root_bus > > arch/powerpc/kernel/pci-common.c: bus = > pci_create_root_bus(hose->parent, hose->first_busno, I thought I addressed this one, didn't I? > arch/s390/pci/pci.c:zdev->bus = pci_create_root_bus(NULL, > ZPCI_BUS_NR, _root_ops, This one appears to have been removed. There's no pci_create_root_bus() in all arch/s390, as far as I can say. > arch/sparc/kernel/pci.c:bus = pci_create_root_bus(parent, > pbm->pci_first_busno, pbm->pci_ops, I modified this one too, is that not sufficient? > drivers/parisc/dino.c: dino_dev->hba.hba_bus = bus = > pci_create_root_bus(>dev, > drivers/parisc/lba_pci.c: pci_create_root_bus(>dev, > lba_dev->hba.bus_num.start, These two pass NULL as the 4th argument to pci_create_root_bus() and don't need to be updated, AFAICS. > > > > Index: linux/arch/x86/pci/acpi.c > > === > > --- linux.orig/arch/x86/pci/acpi.c > > +++ linux/arch/x86/pci/acpi.c > > @@ -450,6 +450,7 @@ struct
Re: [PATCH 1/9] can: add tx/rx LED trigger support
Hello Fabio! Am 2012-12-16 12:08, schrieb Fabio Baltieri: This patch implements the functions to add two LED triggers, named -tx and -rx, to a canbus device driver. Triggers are called from specific handlers by each CAN device driver and can be disabled altogether with a Kconfig option. The implementation keeps the LED on when the interface is UP and blinks the LED on network activity at a configurable rate. This only supports can-dev based drivers, as it uses some support field in the can_priv structure. Supported drivers should call devm_can_led_init() and can_led_event() as needed. Cleanup is handled automatically by devres, so no *_exit function is needed. Supported events are: - CAN_LED_EVENT_OPEN: turn on tx/rx LEDs - CAN_LED_EVENT_STOP: turn off tx/rx LEDs - CAN_LED_EVENT_TX: trigger tx LED blink - CAN_LED_EVENT_RX: trigger tx LED blink Why there is no patch for any usb can device? Can this be done in a more general way, except patching every driver? regards, Bernd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 16.12.2012 23:15, schrieb Alessandro Zummo: On Tue, 11 Dec 2012 10:40:01 +0100 Lars-Peter Clausen wrote: Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...). Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc for v4. Still reading e-mails ;) Andrew monitors the rtc mailing list and picks up the patches that do not need to go in any arch's main tree, which is the suggested way as, with modern chipsets, the RTCs shares hw with many other drivers. Reading just the latest patch (v5) might be faster. ;) It basically doesn't do much. On call of read_time() a so called report with the time values (year, month, ...) is requested from the device, rtc_time is filled with them, done. Regards, Alexander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] cpuidle: fix sysfs output for power_usage
On Sat, Dec 15, 2012 at 01:03:02AM +0100, Rafael J. Wysocki wrote: > On Friday, December 14, 2012 03:17:37 PM Sivaram Nair wrote: > > cpuidle_state->power_usage is signed; so change the corresponding sysfs > > ops to output signed value instead of unsigned. > > What's actually wrong with printing it as an unsigned int? power_usage could have negative values (for example cpuidle/driver.c inits this value to -1, -2 etc. when drv->power_specified is not set) and these shows up badly in the sysfs output. regards, Sivaram -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
On Sun, Dec 16, 2012 at 4:44 PM, Pablo Neira Ayuso wrote: >> What happened to this? OpenWRT is still carrying it, and it broke in >> 3.7. Here's a completely untested update... > > I requested Kevin to resend a new version based on the current kernel > tree while spinning on old pending patches since I have no access to > that hardware, but no luck. > > So I'll review this and, since OpenWRT is carrying, I guess we can get > this into net-next merge window. Sorry, been putting it off since the OpenWRT version has worked flawlessly... I just reassembled my test rig and I'll get you a working patch this week. Is it OK to use git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git as the baseline? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf test: Check python path on attr test
From: Namhyung Kim
Current perf test code tries to execute python version 2 in order to
test attributes on perf_event_open syscall. However it's not default
python version anymore a system can have python v3 only or v2 with a
different name (e.g. python2). So if there's no such python
interpreter with the name 'python', the test would fail like this
(yes, it's happened on my new archlinux laptop :).
13: struct perf_event_attr setup :sh: python: command not found
FAILED!
As we can pass name of the python interpreter on make, use it for
the attr test also.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile | 2 +-
tools/perf/tests/attr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 7d6d2846477b..2e9a287b3a23 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -952,7 +952,7 @@ $(OUTPUT)util/exec_cmd.o: util/exec_cmd.c
$(OUTPUT)PERF-CFLAGS
$(OUTPUT)tests/attr.o: tests/attr.c $(OUTPUT)PERF-CFLAGS
$(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) \
- '-DBINDIR="$(bindir_SQ)"' \
+ '-DBINDIR="$(bindir_SQ)"' -DPYTHON='"$(PYTHON_WORD)"' \
$<
$(OUTPUT)util/config.o: util/config.c $(OUTPUT)PERF-CFLAGS
diff --git a/tools/perf/tests/attr.c b/tools/perf/tests/attr.c
index 25638a986257..6a6be5ea1311 100644
--- a/tools/perf/tests/attr.c
+++ b/tools/perf/tests/attr.c
@@ -146,7 +146,7 @@ static int run_dir(const char *d, const char *perf)
{
char cmd[3*PATH_MAX];
- snprintf(cmd, 3*PATH_MAX, "python %s/attr.py -d %s/attr/ -p %s %s",
+ snprintf(cmd, 3*PATH_MAX, PYTHON " %s/attr.py -d %s/attr/ -p %s %s",
d, d, perf, verbose ? "-v" : "");
return system(cmd);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] charger-manager: Fix bug when check dropped voltage after fullbatt event
On 12/17/2012 03:53 PM, Anton Vorontsov wrote: > On Thu, Nov 22, 2012 at 04:53:51PM +0900, Chanwoo Choi wrote: >> This patch check difference value between current voltage of battery >> and desc->fullbatt_uV whether positve or negative number. If difference >> value is negative number when current voltage of battery is larger than >> desc->fullbatt_uV, charger-manager return immediately because battery >> is fully charged. >> >> Signed-off-by: Chanwoo Choi >> Signed-off-by: Myungjoo Ham >> Signed-off-by: Kyungmin Park >> --- >> drivers/power/charger-manager.c |9 ++--- >> 1 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/power/charger-manager.c >> b/drivers/power/charger-manager.c >> index ee039b9..17130c7 100644 >> --- a/drivers/power/charger-manager.c >> +++ b/drivers/power/charger-manager.c >> @@ -468,7 +468,9 @@ static void fullbatt_vchk(struct work_struct *work) >> struct charger_manager *cm = container_of(dwork, >> struct charger_manager, fullbatt_vchk_work); >> struct charger_desc *desc = cm->desc; >> -int batt_uV, err, diff; >> +int batt_uV; >> +int err; >> +int diff; > > I applied the patch, but dropped this part. This is an unrelated style > fix, and, if anything, it desires a separate patch (possibly 'fixing' the > whole file/driver). > > Thanks! > Thanks for your comment and applied it. I will re-send other patch for fixing coding style. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit
> -Original Message- > From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of > Yinghai Lu > Sent: Sunday, December 16, 2012 6:02 PM > To: Yu, Fenghua > Cc: H. Peter Anvin; Ingo Molnar; Thomas Gleixner; Mallick, Asit K; > Tigran Aivazian; Andreas Herrmann; Borislav Petkov; linux-kernel; x86 > Subject: Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64- > bit > > On Sun, Dec 16, 2012 at 4:42 PM, Yinghai Lu wrote: > > On Sun, Dec 16, 2012 at 3:59 PM, Yu, Fenghua > wrote: > >> > >>> it has to be rebased after #PF handler version. otherwise it can > not > >>> handle for framdisk that is loaded after 1G. > >>> > >>> Fenghua, > >>> > >>> can you post your boot log with 64bit with your patch? > >>> > >>> Yinghai > >> > >> Attached is dmesg with the patches. > >> > > > > yes, your laptop only have 1G ram, and > > > > [0.00] e820: BIOS-provided physical RAM map: > > [0.00] BIOS-e820: [mem 0x-0x0009d7ff] > usable > > [0.00] BIOS-e820: [mem 0x0009d800-0x0009] > reserved > > [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] > reserved > > [0.00] BIOS-e820: [mem 0x000e-0x000f] > reserved > > [0.00] BIOS-e820: [mem 0x0010-0x3e6a] > usable > > [0.00] BIOS-e820: [mem 0x3e6b-0x3e6ccfff] > ACPI data > > [0.00] BIOS-e820: [mem 0x3e6cd000-0x3e6f] > ACPI NVS > > [0.00] BIOS-e820: [mem 0x3e70-0x3eff] > reserved > > [0.00] BIOS-e820: [mem 0xf000-0xf3ff] > reserved > > [0.00] BIOS-e820: [mem 0xfec0-0xfec0] > reserved > > [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] > reserved > > [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] > reserved > > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] > reserved > > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] > reserved > > [0.00] BIOS-e820: [mem 0xff00-0x] > reserved > > > > ramdisk is at > > RAMDISK: [mem 0x27608000-0x2fafbfff] > > > > and current kernel default set 1G to kernel mapping. so it happens to > > work with your patchset. > > > > please find one sytem with 4G or more to test it. > > > > and you may need to rebase your patches on top of my for-x86-boot > > branch with working #PF handler set page table patch. > > > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux- > yinghai.gi > > t > > for-x86-boot > > also you did not consider initrd relocating > > please check attached fix, and see if you can fold in into you next > posting. > > Thanks > > Yinghai Your fix is based on old v2 patchset. Today's v3 patchset fixes this issue already. Basically it uses offset instead of pointer in initrd image and converts offset to pointer when it accesses the microcode in initrd image. It uses pointers after boot time. Thanks. -Fenghua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI: Simplify namespace scanning for devices
On Sun, Dec 16, 2012 at 2:31 PM, Rafael J. Wysocki wrote: > On Sunday, December 16, 2012 09:36:49 AM Yinghai Lu wrote: > There you go: > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git > acpi-scan-temp > >> I'd like to rebase for-pci-root-bus-hotplug patches, so what should be base? > rebase all pci patches (without four patches about drivers_autoprobe and remove acpi_pci_root_start) on top your branch. root bus hotplug seems work well without problem. Thanks a lot. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] charger-manager: Fix bug related to checking fully charged state of battery
On Thu, Nov 22, 2012 at 04:53:46PM +0900, Chanwoo Choi wrote: > This patch fix bug related to checking fully charged state of battery > when charger-manager call is_full_charged() function. After reading > property of charger/fuel-gauge through power_supply API, val.intval is > more than 1. So, is_full_charged() function always return true. If true, > battery means fully charged state. > > Signed-off-by: Chanwoo Choi > Signed-off-by: Myungjoo Ham > Signed-off-by: Kyungmin Park > --- Applied, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] New Nokia RX-51 power supply battery driver
On Wed, Nov 21, 2012 at 11:20:43AM -0800, Tony Lindgren wrote: > * Anton Vorontsov [121119 10:25]: > > On Mon, Nov 19, 2012 at 01:18:29PM +0100, Pali Rohár wrote: > > [...] > > > Ok. Here is missing patch which register this driver in Nokia N900 board > > > code. Without it driver is not loaded. > > > > Cc'ing OMAP folks. > > Looks OK to me queue with the other patches in the series: > > Acked-by: Tony Lindgren Applied, thanks! (I'll make a second pull request for this window, but no sure if it will make it. We will see.) Thanks, Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] Input updates for 3.7-rc0
*** The subject should read 3.8-rc0 of course *** On Sun, Dec 16, 2012 at 10:25:04PM -0800, Dmitry Torokhov wrote: > Hi Linus, > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus > or > master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus > > to receive updates for the input subsystem. As usual, there are a couple > of new drivers, input core now supports managed input devices (devres), > a slew of drivers now have device tree support and a bunch of fixes and > cleanups. > > There will be 2 conflicts: one in arch/arm/mach-ux500/board-mop500-stuib.c, > and another in drivers/input/touchscreen/ti_tscadc.c (which was renamed > into ti_am335x_tsc). > > Thanks! > > Changelog: > - > > Aaro Koskinen (2): > Input: i8042-io - fix up region handling on MIPS > Input: add Retu power button driver. > > Alban Bedel (2): > Input: tca8418_keypad - add support for device tree bindings > Input: tca8418_keypad - add support for shared interrupt > > Alexander Shiyan (2): > Input: remove Compaq iPAQ H3600 (Bitsy) touchscreen driver > Input: gpio-keys-polled - honor 'autorepeat' setting in platform data > > Andreas Pretzsch (1): > Input: imx_keypad - only set enabled columns to open-drain > > Andy Shevchenko (1): > Input: ALPS - print small buffers via %*ph > > AnilKumar Ch (1): > Input: matrix-keypad - add device tree support > > Ashish Jangam (1): > Input: add DA9055 Onkey driver > > Bill Pemberton (6): > Input: serio - remove CONFIG_HOTPLUG ifdefs > Input: remove use of __devexit_p > Input: remove use of __devinitdata > Input: remove use of __devinitconst > Input: remove use of __devinit > Input: remove use of __devexit > > Deepak Sikri (1): > Input: spear-keyboard - fix for balancing the enable_irq_wake > > Diego Calleja (1): > Input: wacom - fix touch support for Bamboo Fun CTH-461 > > Dmitry Torokhov (15): > Input: arc_ps2 - switch to using managed resources > Input: fix sparse warning in multitouch code > Input: fix sparse warning in __input_release_device() > Input: introduce managed input devices (add devres support) > Input: marix-keymap - automatically allocate memory for keymap > OMAP: nokia770: remove custom implementation of > ads7846_get_pendown_state > Input: stmpe-keypad - add support for Device Tree bindings > Input: gpio_keys - report initial state when opening the device > Input: tca8418_keypad - use a temporary variable for parent device > Input: tca8418_keypad - use dev_get_platdata() to retrieve platform data > Input: tca8418_keypad - move device ID tables closer to where they are > used > Input: tca8418_keypad - increase severity of failures in probe() > Input: tca8418-keypad - switch to using managed resources > Input: gpio_keys - switch to using gpio_request_one() > Input: gpio_keys_polled - switch to using gpio_request_one() > > Florian Fainelli (1): > Input: matrix-keymap - provide a proper module license > > Guillermo A. Amaral (2): > Input: xpad - minor formatting fixes > Input: xpad - add a few new VID/PID combinations > > Henrik Rydberg (1): > Input: document new members of struct input_dev > > Javier Martin (1): > Input: qt2160 - fix qt2160_write() implementation > > Jonas Aaberg (1): > Input: gpio_keys - disable hardware on suspend > > Kees Cook (2): > Input: remove CONFIG_EXPERIMENTAL from keyboard drivers > Input: remove CONFIG_EXPERIMENTAL from miscellaneous drivers > > Lee Jones (4): > ARM: ux500: Strip out duplicate touch screen platform information > Input: bu21013_ts - request regulator that actually exists > Input: bu21013_ts - move GPIO init and exit functions into the driver > Input: bu21013_ts - add support for Device Tree booting > > Mark Brown (3): > Input: wm831x-ts - remove unneeded clearing of driver data > Input: wm831x-ts - convert to devm_kzalloc() > Input: wm831x-on - convert to devm_kzalloc() > > Mischa Jonker (1): > Input: serio - add ARC PS/2 driver > > Peter Popovec (1): > Input: walkera0701 - fix crash on startup > > Peter Ujfalusi (1): > Input: twl4030-pwrbutton - switch to using TWL_MODULE_PM_MASTER define > > Ping Cheng (4): > Input: wacom - clean up device type code > Input: wacom - add support for 2 new multi-touch tablets (0x100 and > 0x101) > Input: wacom - simplify type check for newer V5 devices > Input: wacom - add support for a new MT device (0x4001) > > Rolf Eike Beer (1): > Input: HIL - remove one goto > > Sachin Kamat (1): > Input: samsung-keypad - switch to using managed resources > > Sascha Hauer (1): > Input: pwm-beeper - add devicetree probing support > > Shubhrajyoti D (1): > Input:
Re: [PATCH v2 2/3] charger-manager: Fix bug when check dropped voltage after fullbatt event
On Thu, Nov 22, 2012 at 04:53:51PM +0900, Chanwoo Choi wrote: > This patch check difference value between current voltage of battery > and desc->fullbatt_uV whether positve or negative number. If difference > value is negative number when current voltage of battery is larger than > desc->fullbatt_uV, charger-manager return immediately because battery > is fully charged. > > Signed-off-by: Chanwoo Choi > Signed-off-by: Myungjoo Ham > Signed-off-by: Kyungmin Park > --- > drivers/power/charger-manager.c |9 ++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c > index ee039b9..17130c7 100644 > --- a/drivers/power/charger-manager.c > +++ b/drivers/power/charger-manager.c > @@ -468,7 +468,9 @@ static void fullbatt_vchk(struct work_struct *work) > struct charger_manager *cm = container_of(dwork, > struct charger_manager, fullbatt_vchk_work); > struct charger_desc *desc = cm->desc; > - int batt_uV, err, diff; > + int batt_uV; > + int err; > + int diff; I applied the patch, but dropped this part. This is an unrelated style fix, and, if anything, it desires a separate patch (possibly 'fixing' the whole file/driver). Thanks! > /* remove the appointment for fullbatt_vchk */ > cm->fullbatt_vchk_jiffies_at = 0; > @@ -482,8 +484,9 @@ static void fullbatt_vchk(struct work_struct *work) > return; > } > > - diff = desc->fullbatt_uV; > - diff -= batt_uV; > + diff = desc->fullbatt_uV - batt_uV; > + if (diff < 0) > + return; > > dev_info(cm->dev, "VBATT dropped %duV after full-batt.\n", diff); > > -- > 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tuntap: fix ambigious multiqueue API
- Original Message -
> The current multiqueue API is ambigious which may confuse both user
> and LSM to
> do things correctly:
>
> - Both TUNSETIFF and TUNSETQUEUE could be used to create the queues
> of a tuntap
> device.
> - TUNSETQUEUE were used to disable and enable a specific queue of the
> device. But since the state of tuntap were completely removed from
> the queue,
> it could be used to attach to another device (there's no such kind
> of
> requirement currently, and it needs new kind of LSM policy.
> - TUNSETQUEUE could be used to attach to a persistent device without
> any
> queues. This kind of attching bypass the necessary checking during
> TUNSETIFF
> and may lead unexpected result.
>
> So this patch tries to make a cleaner and simpler API by:
>
> - Only allow TUNSETIFF to create queues.
> - TUNSETQUEUE could be only used to disable and enabled the queues of
> a device,
> and the state of the tuntap device were not detachd from the queues
> when it
> was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and
> with the
>same device.
>
> This is done by introducing a list which keeps track of all queues
> which were
> disabled. The queue would be moved between this list and tfiles[]
> array when it
> was enabled/disabled. A pointer of the tun_struct were also introdued
> to track
> the device it belongs to when it was disabled.
>
> After the change, the isolation between management and application
> could be done
> through: TUNSETIFF were only called by management software and
> TUNSETQUEUE were
> only called by application.For LSM/SELinux, the things left is to do
> proper
> check during tun_set_queue() if needed.
>
> Signed-off-by: Jason Wang
> ---
> drivers/net/tun.c | 86
> ++--
> 1 files changed, 63 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 2ac2164..6f2053d 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -138,6 +138,8 @@ struct tun_file {
> /* only used for fasnyc */
> unsigned int flags;
> u16 queue_index;
> + struct list_head next;
> + struct tun_struct *detached;
> };
>
> struct tun_flow_entry {
> @@ -182,6 +184,8 @@ struct tun_struct {
> struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> struct timer_list flow_gc_timer;
> unsigned long ageing_time;
> + unsigned int numdisabled;
> + struct list_head disabled;
> };
>
> static inline u32 tun_hashfn(u32 rxhash)
> @@ -386,6 +390,23 @@ static void tun_set_real_num_queues(struct
> tun_struct *tun)
> netif_set_real_num_rx_queues(tun->dev, tun->numqueues);
> }
>
> +static void tun_disable_queue(struct tun_struct *tun, struct
> tun_file *tfile)
> +{
> + tfile->detached = tun;
> + list_add_tail(>next, >disabled);
> + ++tun->numdisabled;
> +}
> +
> +struct tun_struct *tun_enable_queue(struct tun_file *tfile)
> +{
> + struct tun_struct *tun = tfile->detached;
> +
> + tfile->detached = NULL;
> + list_del_init(>next);
> + --tun->numdisabled;
> + return tun;
> +}
> +
> static void __tun_detach(struct tun_file *tfile, bool clean)
> {
> struct tun_file *ntfile;
> @@ -407,20 +428,25 @@ static void __tun_detach(struct tun_file
> *tfile, bool clean)
> ntfile->queue_index = index;
>
> --tun->numqueues;
> - sock_put(>sk);
> + if (clean)
> + sock_put(>sk);
> + else
> + tun_disable_queue(tun, tfile);
>
> synchronize_net();
> tun_flow_delete_by_queue(tun, tun->numqueues + 1);
> /* Drop read queue */
> skb_queue_purge(>sk.sk_receive_queue);
> tun_set_real_num_queues(tun);
> -
> - if (tun->numqueues == 0 && !(tun->flags & TUN_PERSIST))
> - if (dev->reg_state == NETREG_REGISTERED)
> - unregister_netdevice(dev);
> - }
> + } else if (tfile->detached && clean)
> + tun = tun_enable_queue(tfile);
>
> if (clean) {
> + if (tun && tun->numqueues == 0 && tun->numdisabled == 0 &&
> + !(tun->flags & TUN_PERSIST))
> + if (tun->dev->reg_state == NETREG_REGISTERED)
> + unregister_netdevice(tun->dev);
> +
> BUG_ON(!test_bit(SOCK_EXTERNALLY_ALLOCATED,
>>socket.flags));
> sk_release_kernel(>sk);
> @@ -437,7 +463,7 @@ static void tun_detach(struct tun_file *tfile,
> bool clean)
> static void tun_detach_all(struct net_device *dev)
> {
> struct tun_struct *tun = netdev_priv(dev);
> - struct tun_file *tfile;
> + struct tun_file *tfile, *tmp;
> int i, n = tun->numqueues;
>
> for (i = 0; i < n; i++) {
> @@ -458,6 +484,12 @@ static void tun_detach_all(struct net_device
> *dev)
>
[PATCH 01/14] perf tools: Keep group information
From: Namhyung Kim
Add a few of group-related field in struct perf_{evlist,evsel} so that
the group information in a evlist can be known easily. It only counts
groups which have more than 1 members since leader-only groups are
treated as non-group events.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/evlist.c | 7 ++-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.h| 6 ++
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 ++
6 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index dc8aee97a488..eddd5ebcd690 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -117,6 +117,9 @@ void __perf_evlist__set_leader(struct list_head *list)
struct perf_evsel *evsel, *leader;
leader = list_entry(list->next, struct perf_evsel, node);
+ evsel = list_entry(list->prev, struct perf_evsel, node);
+
+ leader->nr_members = evsel->idx - leader->idx + 1;
list_for_each_entry(evsel, list, node) {
if (evsel != leader)
@@ -126,8 +129,10 @@ void __perf_evlist__set_leader(struct list_head *list)
void perf_evlist__set_leader(struct perf_evlist *evlist)
{
- if (evlist->nr_entries)
+ if (evlist->nr_entries) {
+ evlist->nr_groups = evlist->nr_entries > 1 ? 1 : 0;
__perf_evlist__set_leader(>entries);
+ }
}
int perf_evlist__add_default(struct perf_evlist *evlist)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 457e2350d21d..73579a25a93e 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -21,6 +21,7 @@ struct perf_evlist {
struct list_head entries;
struct hlist_head heads[PERF_EVLIST__HLIST_SIZE];
int nr_entries;
+ int nr_groups;
int nr_fds;
int nr_mmaps;
int mmap_len;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 9cb8a0215711..3b48b87d7e2d 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -73,6 +73,7 @@ struct perf_evsel {
boolneeds_swap;
/* parse modifier helper */
int exclude_GH;
+ int nr_members;
struct perf_evsel *leader;
char*group_name;
};
@@ -251,4 +252,9 @@ struct perf_attr_details {
int perf_evsel__fprintf(struct perf_evsel *evsel,
struct perf_attr_details *details, FILE *fp);
+
+static inline int perf_evsel__group_idx(struct perf_evsel *evsel)
+{
+ return evsel->idx - evsel->leader->idx;
+}
#endif /* __PERF_EVSEL_H */
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 2d8d53bec17e..398f04c01f7e 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -843,6 +843,7 @@ int parse_events(struct perf_evlist *evlist, const char
*str,
if (!ret) {
int entries = data.idx - evlist->nr_entries;
perf_evlist__splice_list_tail(evlist, , entries);
+ evlist->nr_groups += data.nr_groups;
return 0;
}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index b7af80b8bdda..330b8896876b 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -65,6 +65,7 @@ struct parse_events__term {
struct parse_events_data__events {
struct list_head list;
int idx;
+ int nr_groups;
};
struct parse_events_data__terms {
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 0f9914ae6bac..7f2d63afcf38 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -23,6 +23,14 @@ do { \
YYABORT; \
} while (0)
+static inc_group_count(struct list_head *list,
+ struct parse_events_data__events *data)
+{
+ /* Count groups only have more than 1 members */
+ if (!list_is_last(list->next, list))
+ data->nr_groups++;
+}
+
%}
%token PE_START_EVENTS PE_START_TERMS
@@ -123,6 +131,7 @@ PE_NAME '{' events '}'
{
struct list_head *list = $3;
+ inc_group_count(list, _data);
parse_events__set_leader($1, list);
$$ = list;
}
@@ -131,6 +140,7 @@ PE_NAME '{' events '}'
{
struct list_head *list = $2;
+ inc_group_count(list, _data);
parse_events__set_leader(NULL, list);
$$ = list;
}
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/14] perf gtk/browser: Trim column header string when event group enabled
From: Namhyung Kim
When event group feature is enabled, each column header is expanded to
match with the whole group column width. But this is not needed for
GTK+ browser since it usually use variable-width fonts. So trim it.
As we have ltrim() implementation in builtin-script.c move it to the
more generic location of util/string.c.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Cc: Feng Tang
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-script.c | 12
tools/perf/ui/gtk/browser.c | 2 +-
tools/perf/util/string.c| 18 ++
tools/perf/util/util.h | 1 +
4 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index b363e7b292b2..74b9f740794b 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -909,18 +909,6 @@ static const char *ends_with(const char *str, const char
*suffix)
return NULL;
}
-static char *ltrim(char *str)
-{
- int len = strlen(str);
-
- while (len && isspace(*str)) {
- len--;
- str++;
- }
-
- return str;
-}
-
static int read_script_info(struct script_desc *desc, const char *filename)
{
char line[BUFSIZ], *p;
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index a82e903703b4..8de928848f79 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -202,7 +202,7 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists)
perf_hpp__for_each_format(fmt) {
fmt->header(fmt, );
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
- -1, s,
+ -1, ltrim(s),
renderer, "markup",
col_idx++, NULL);
}
diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index 346707df04b9..29c7b2cb2521 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -332,6 +332,24 @@ char *strxfrchar(char *s, char from, char to)
}
/**
+ * ltrim - Removes leading whitespace from @s.
+ * @s: The string to be stripped.
+ *
+ * Return pointer to the first non-whitespace character in @s.
+ */
+char *ltrim(char *s)
+{
+ int len = strlen(s);
+
+ while (len && isspace(*s)) {
+ len--;
+ s++;
+ }
+
+ return s;
+}
+
+/**
* rtrim - Removes trailing whitespace from @s.
* @s: The string to be stripped.
*
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index c2330918110c..2a854a133b5b 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -265,6 +265,7 @@ bool is_power_of_2(unsigned long n)
size_t hex_width(u64 v);
int hex2u64(const char *ptr, u64 *val);
+char *ltrim(char *s);
char *rtrim(char *s);
void dump_stack(void);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/14] perf gtk/browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Unlike other hpp backend, GTK+ needs to print dummy 0.00% output since
it's displayed with variable width fonts. So that simply skipping
with %*s trick won't work well here.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/browser.c | 117 +++-
1 file changed, 94 insertions(+), 23 deletions(-)
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 0d94b3ba054a..a82e903703b4 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -45,34 +45,104 @@ static const char *perf_gtk__get_percent_color(double
percent)
return NULL;
}
-#define HPP__COLOR_FN(_name, _field)
\
-static int
\
-perf_gtk__hpp_color_ ## _name(struct perf_hpp_fmt *fmt __maybe_unused,
\
-struct perf_hpp *hpp,
\
-struct hist_entry *he)
\
+static int perf_gtk__percent_color_snprintf(char *buf, size_t size,
+ double percent)
+{
+ int ret = 0;
+ const char *markup;
+
+ markup = perf_gtk__get_percent_color(percent);
+ if (markup)
+ ret += scnprintf(buf, size, markup);
+
+ ret += scnprintf(buf + ret, size - ret, "%6.2f%%", percent);
+
+ if (markup)
+ ret += scnprintf(buf + ret, size - ret, "");
+
+ return ret;
+}
+
+
+static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *))
+{
+ int ret;
+ double percent = 0.0;
+ struct hists *hists = he->hists;
+
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
+
+ ret = perf_gtk__percent_color_snprintf(hpp->buf, hpp->size, percent);
+
+ if (symbol_conf.event_group) {
+ int prev_idx, idx_delta;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
+
+ if (nr_members <= 1)
+ return ret;
+
+ prev_idx = perf_evsel__group_idx(evsel);
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ u64 period = get_field(pair);
+ u64 total = pair->hists->stats.total_period;
+
+ evsel = hists_to_evsel(pair->hists);
+ idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
+
+ while (idx_delta--) {
+ ret += scnprintf(hpp->buf + ret, hpp->size
-ret, " ");
+ ret +=
perf_gtk__percent_color_snprintf(hpp->buf + ret,
+
hpp->size - ret,
+ 0.0);
+ }
+
+ percent = 100.0 * period / total;
+ ret += scnprintf(hpp->buf + ret, hpp->size -ret, " ");
+ ret += perf_gtk__percent_color_snprintf(hpp->buf + ret,
+ hpp->size - ret,
+ percent);
+
+ prev_idx = perf_evsel__group_idx(evsel);
+ }
+
+ idx_delta = nr_members - prev_idx - 1;
+
+ while (idx_delta--) {
+ ret += scnprintf(hpp->buf + ret, hpp->size -ret, " ");
+ ret += perf_gtk__percent_color_snprintf(hpp->buf + ret,
+ hpp->size - ret,
+ 0.0);
+ }
+ }
+ return ret;
+}
+
+#define __HPP_COLOR_PERCENT_FN(_type, _field)
\
+static u64 he_get_##_field(struct hist_entry *he)
\
{
\
- struct hists *hists = he->hists;
\
- double percent = 100.0 * he->stat._field / hists->stats.total_period;
\
- const char *markup;
\
- int ret = 0;
\
+ return he->stat._field;
\
+}
[PATCH 07/14] perf ui/hist: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Thanks to Arnaldo for suggesting a better way to print group members
without allocating temporary array.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 348 +
tools/perf/ui/stdio/hist.c | 2 +
2 files changed, 167 insertions(+), 183 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 0db3b4480604..ea605be78a29 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -3,223 +3,194 @@
#include "../util/hist.h"
#include "../util/util.h"
#include "../util/sort.h"
-
+#include "../util/evsel.h"
/* hist period print (hpp) functions */
-static int hpp__header_overhead(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp)
-{
- return scnprintf(hpp->buf, hpp->size, "Overhead");
-}
-
-static int hpp__width_overhead(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp __maybe_unused)
-{
- return 8;
-}
-
-static int hpp__color_overhead(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", percent);
-}
-static int hpp__entry_overhead(struct perf_hpp_fmt *_fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : " %6.2f%%";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_sys(struct perf_hpp_fmt *_fmt __maybe_unused,
- struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
-
- return scnprintf(hpp->buf, hpp->size, fmt, "sys");
-}
-
-static int hpp__width_overhead_sys(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
-}
+typedef int (*hpp_snprint_fn)(char *buf, size_t size, const char *fmt, ...);
-static int hpp__color_overhead_sys(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
-
- return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
-}
-
-static int hpp__entry_overhead_sys(struct perf_hpp_fmt *_fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
-
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
-
-static int hpp__header_overhead_us(struct perf_hpp_fmt *_fmt __maybe_unused,
- struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
-
- return scnprintf(hpp->buf, hpp->size, fmt, "user");
-}
-
-static int hpp__width_overhead_us(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
-}
-
-static int hpp__color_overhead_us(struct perf_hpp_fmt *fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
+static int __hpp__percent_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *),
+ const char *fmt, hpp_snprint_fn print_fn)
{
+ int ret;
+ double percent = 0.0;
struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_us / hists->stats.total_period;
- return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
-}
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
-static int hpp__entry_overhead_us(struct perf_hpp_fmt *_fmt __maybe_unused,
- struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_us / hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
+ ret = print_fn(hpp->buf, hpp->size, fmt, percent);
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
+ if
[PATCH 11/14] perf report: Bypass non-leader events when event group is enabled
From: Namhyung Kim
Since we have all necessary information in the leader events and
other members don't, bypass members. Member events will be shown
along with the leaders if event group is enabled.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 4
tools/perf/ui/browsers/hists.c | 41 +++--
tools/perf/ui/gtk/browser.c| 4
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index a7b4cbe429b0..a1082d547150 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -319,6 +319,10 @@ static int perf_evlist__tty_browse_hists(struct
perf_evlist *evlist,
struct hists *hists = >hists;
const char *evname = perf_evsel__name(pos);
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
hists__fprintf_nr_sample_events(hists, evname, stdout);
hists__fprintf(hists, true, 0, 0, stdout);
fprintf(stdout, "\n\n");
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index b467546ce7d4..69278b53667c 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1701,8 +1701,19 @@ out:
return key;
}
+static bool filter_group_entries(struct ui_browser *self __maybe_unused,
+void *entry)
+{
+ struct perf_evsel *evsel = list_entry(entry, struct perf_evsel, node);
+
+ if (symbol_conf.event_group && !perf_evsel__is_group_leader(evsel))
+ return true;
+
+ return false;
+}
+
static int __perf_evlist__tui_browse_hists(struct perf_evlist *evlist,
- const char *help,
+ int nr_entries, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
@@ -1713,7 +1724,8 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
.refresh= ui_browser__list_head_refresh,
.seek = ui_browser__list_head_seek,
.write = perf_evsel_menu__write,
- .nr_entries = evlist->nr_entries,
+ .filter = filter_group_entries,
+ .nr_entries = nr_entries,
.priv = evlist,
},
.env = env,
@@ -1729,20 +1741,37 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
menu.b.width = line_len;
}
- return perf_evsel_menu__run(, evlist->nr_entries, help, hbt);
+ return perf_evsel_menu__run(, nr_entries, help, hbt);
}
int perf_evlist__tui_browse_hists(struct perf_evlist *evlist, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
- if (evlist->nr_entries == 1) {
+ int nr_entries = evlist->nr_entries;
+
+single_entry:
+ if (nr_entries == 1) {
struct perf_evsel *first = list_entry(evlist->entries.next,
struct perf_evsel, node);
const char *ev_name = perf_evsel__name(first);
- return perf_evsel__hists_browse(first, evlist->nr_entries, help,
+
+ return perf_evsel__hists_browse(first, nr_entries, help,
ev_name, false, hbt, env);
}
- return __perf_evlist__tui_browse_hists(evlist, help, hbt, env);
+ if (symbol_conf.event_group) {
+ struct perf_evsel *pos;
+
+ nr_entries = 0;
+ list_for_each_entry(pos, >entries, node)
+ if (perf_evsel__is_group_leader(pos))
+ nr_entries++;
+
+ if (nr_entries == 1)
+ goto single_entry;
+ }
+
+ return __perf_evlist__tui_browse_hists(evlist, nr_entries, help,
+ hbt, env);
}
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 8de928848f79..2f1652b1bc05 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -335,6 +335,10 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
[PATCH 06/14] perf hists: Resort hist entries using group members for output
From: Namhyung Kim
When event group is enabled, sorting hist entries on periods for
output should consider groups members' period also. To do that, build
period table using link/pair information and compare the table.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/evsel.h | 2 ++
tools/perf/util/hist.c | 59 -
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index 3b48b87d7e2d..e86402ddaa71 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -78,6 +78,8 @@ struct perf_evsel {
char*group_name;
};
+#define hists_to_evsel(h) container_of(h, struct perf_evsel, hists)
+
struct cpu_map;
struct thread_map;
struct perf_evlist;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 677d1c96be02..7ed93842d489 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -4,6 +4,7 @@
#include "hist.h"
#include "session.h"
#include "sort.h"
+#include "evsel.h"
#include
static bool hists__filter_entry_by_dso(struct hists *hists,
@@ -529,6 +530,62 @@ void hists__collapse_resort_threaded(struct hists *hists)
* reverse the map, sort on period.
*/
+static int period_cmp(u64 period_a, u64 period_b)
+{
+ if (period_a > period_b)
+ return 1;
+ if (period_a < period_b)
+ return -1;
+ return 0;
+}
+
+static int hist_entry__sort_on_period(struct hist_entry *a,
+ struct hist_entry *b)
+{
+ int ret;
+ int i, nr_members;
+ struct perf_evsel *evsel;
+ struct hist_entry *pair;
+ u64 *periods_a, *periods_b;
+
+ ret = period_cmp(a->stat.period, b->stat.period);
+ if (ret || !symbol_conf.event_group)
+ return ret;
+
+ evsel = hists_to_evsel(a->hists);
+ nr_members = evsel->nr_members;
+ if (nr_members <= 1)
+ return ret;
+
+ periods_a = zalloc(sizeof(periods_a) * nr_members);
+ periods_b = zalloc(sizeof(periods_b) * nr_members);
+
+ if (!periods_a || !periods_b)
+ goto out;
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_a[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_b[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ for (i = 1; i < nr_members; i++) {
+ ret = period_cmp(periods_a[i], periods_b[i]);
+ if (ret)
+ break;
+ }
+
+out:
+ free(periods_a);
+ free(periods_b);
+
+ return ret;
+}
+
static void __hists__insert_output_entry(struct rb_root *entries,
struct hist_entry *he,
u64 min_callchain_hits)
@@ -545,7 +602,7 @@ static void __hists__insert_output_entry(struct rb_root
*entries,
parent = *p;
iter = rb_entry(parent, struct hist_entry, rb_node);
- if (he->stat.period > iter->stat.period)
+ if (hist_entry__sort_on_period(he, iter) > 0)
p = &(*p)->rb_left;
else
p = &(*p)->rb_right;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/14] perf header: Add HEADER_GROUP_DESC feature
From: Namhyung Kim
Save group relationship information so that it can be restored when
perf report is running.
Cc: Jiri Olsa
Cc: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-record.c | 3 +
tools/perf/util/header.c| 164
tools/perf/util/header.h| 2 +
3 files changed, 169 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 028de726b832..7e1d67dc8ef9 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -585,6 +585,9 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
goto out_delete_session;
}
+ if (!evsel_list->nr_groups)
+ perf_header__clear_feat(>header, HEADER_GROUP_DESC);
+
/*
* perf_session__delete(session) will be called at perf_record__exit()
*/
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index bb578d2d10f9..f7ecbb796008 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1082,6 +1082,52 @@ static int write_pmu_mappings(int fd, struct perf_header
*h __maybe_unused,
}
/*
+ * File format:
+ *
+ * struct group_descs {
+ * u32 nr_groups;
+ * struct group_desc {
+ * charname[];
+ * u32 leader_idx;
+ * u32 nr_members;
+ * }[nr_groups];
+ * };
+ */
+static int write_group_desc(int fd, struct perf_header *h __maybe_unused,
+ struct perf_evlist *evlist)
+{
+ u32 nr_groups = evlist->nr_groups;
+ struct perf_evsel *evsel;
+ int ret;
+
+ ret = do_write(fd, _groups, sizeof(nr_groups));
+ if (ret < 0)
+ return ret;
+
+ list_for_each_entry(evsel, >entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ const char *name = evsel->group_name ?: "{anon_group}";
+ u32 leader_idx = evsel->idx;
+ u32 nr_members = evsel->nr_members;
+
+ ret = do_write_string(fd, name);
+ if (ret < 0)
+ return ret;
+
+ ret = do_write(fd, _idx, sizeof(leader_idx));
+ if (ret < 0)
+ return ret;
+
+ ret = do_write(fd, _members, sizeof(nr_members));
+ if (ret < 0)
+ return ret;
+ }
+ }
+ return 0;
+}
+
+/*
* default get_cpuid(): nothing gets recorded
* actual implementation must be in arch/$(ARCH)/util/header.c
*/
@@ -1444,6 +1490,31 @@ error:
fprintf(fp, "# pmu mappings: unable to read\n");
}
+static void print_group_desc(struct perf_header *ph, int fd __maybe_unused,
+FILE *fp)
+{
+ struct perf_session *session;
+ struct perf_evsel *evsel;
+ u32 nr = 0;
+
+ session = container_of(ph, struct perf_session, header);
+
+ list_for_each_entry(evsel, >evlist->entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ fprintf(fp, "# group: %s{%s", evsel->group_name ?: "",
+ perf_evsel__name(evsel));
+
+ nr = evsel->nr_members - 1;
+ } else if (nr) {
+ fprintf(fp, ",%s", perf_evsel__name(evsel));
+
+ if (--nr == 0)
+ fprintf(fp, "}\n");
+ }
+ }
+}
+
static int __event_process_build_id(struct build_id_event *bev,
char *filename,
struct perf_session *session)
@@ -1958,6 +2029,98 @@ error:
return -1;
}
+static int process_group_desc(struct perf_file_section *section __maybe_unused,
+ struct perf_header *ph, int fd,
+ void *data __maybe_unused)
+{
+ size_t ret = -1;
+ u32 i, nr, nr_groups;
+ struct perf_session *session;
+ struct perf_evsel *evsel, *leader = NULL;
+ struct group_desc {
+ char *name;
+ u32 leader_idx;
+ u32 nr_members;
+ } *desc;
+
+ if (readn(fd, _groups, sizeof(nr_groups)) != sizeof(nr_groups))
+ return -1;
+
+ if (ph->needs_swap)
+ nr_groups = bswap_32(nr_groups);
+
+ ph->env.nr_groups = nr_groups;
+ if (!nr_groups) {
+ pr_debug("group desc not available\n");
+ return 0;
+ }
+
+ desc = calloc(nr_groups, sizeof(*desc));
+ if (!desc)
+ return -1;
+
+ for (i = 0; i < nr_groups; i++) {
+ desc[i].name = do_read_string(fd, ph);
+ if
[PATCH 02/14] perf test: Add group test conditions
From: Namhyung Kim
As some new fields for handling groups added, check them to be sure to
have valid values in test__group* cases.
Cc: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/tests/parse-events.c | 28
1 file changed, 28 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index 294ffddfbf42..9cd6f3597829 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -22,6 +22,7 @@ static int test__checkevent_tracepoint(struct perf_evlist
*evlist)
struct perf_evsel *evsel = perf_evlist__first(evlist);
TEST_ASSERT_VAL("wrong number of entries", 1 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 0 == evlist->nr_groups);
TEST_ASSERT_VAL("wrong type", PERF_TYPE_TRACEPOINT == evsel->attr.type);
TEST_ASSERT_VAL("wrong sample_type",
PERF_TP_SAMPLE_TYPE == evsel->attr.sample_type);
@@ -34,6 +35,7 @@ static int test__checkevent_tracepoint_multi(struct
perf_evlist *evlist)
struct perf_evsel *evsel;
TEST_ASSERT_VAL("wrong number of entries", evlist->nr_entries > 1);
+ TEST_ASSERT_VAL("wrong number of groups", 0 == evlist->nr_groups);
list_for_each_entry(evsel, >entries, node) {
TEST_ASSERT_VAL("wrong type",
@@ -509,6 +511,7 @@ static int test__group1(struct perf_evlist *evlist)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 2 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 1 == evlist->nr_groups);
/* instructions:k */
evsel = leader = perf_evlist__first(evlist);
@@ -522,6 +525,8 @@ static int test__group1(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* cycles:upp */
evsel = perf_evsel__next(evsel);
@@ -536,6 +541,7 @@ static int test__group1(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", evsel->attr.precise_ip == 2);
TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 1);
return 0;
}
@@ -545,6 +551,7 @@ static int test__group2(struct perf_evlist *evlist)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 3 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 1 == evlist->nr_groups);
/* faults + :ku modifier */
evsel = leader = perf_evlist__first(evlist);
@@ -558,6 +565,8 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* cache-references + :u modifier */
evsel = perf_evsel__next(evsel);
@@ -571,6 +580,7 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 1);
/* cycles:k */
evsel = perf_evsel__next(evsel);
@@ -593,6 +603,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 5 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 2 == evlist->nr_groups);
/* group1 syscalls:sys_enter_open:H */
evsel = leader = perf_evlist__first(evlist);
@@ -609,6 +620,8 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
TEST_ASSERT_VAL("wrong group name",
!strcmp(leader->group_name, "group1"));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* group1 cycles:kppp */
evsel = perf_evsel__next(evsel);
@@ -624,6 +637,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong precise_ip", evsel->attr.precise_ip == 3);
TEST_ASSERT_VAL("wrong leader",
[PATCH 05/14] perf report: Make another loop for linking group hists
From: Namhyung Kim
Now the event grouping viewing requires linking all member hists in a
group to the leader's. Thus hists__output_resort should be called
after linking all events in evlist.
Introduce symbol_conf.event_group flag to determine whether the
feature is enabled or not.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 13 -
tools/perf/util/symbol.h| 3 ++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index fc251005dd3d..a7b4cbe429b0 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -416,8 +416,16 @@ static int __cmd_report(struct perf_report *rep)
hists->symbol_filter_str = rep->symbol_filter_str;
hists__collapse_resort(hists);
- hists__output_resort(hists);
nr_samples += hists->stats.nr_events[PERF_RECORD_SAMPLE];
+
+ /* Non-group events are considered as leader */
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos)) {
+ struct hists *leader_hists = >leader->hists;
+
+ hists__match(leader_hists, hists);
+ hists__link(leader_hists, hists);
+ }
}
if (nr_samples == 0) {
@@ -425,6 +433,9 @@ static int __cmd_report(struct perf_report *rep)
goto out_delete;
}
+ list_for_each_entry(pos, >evlist->entries, node)
+ hists__output_resort(>hists);
+
if (use_browser > 0) {
if (use_browser == 1) {
perf_evlist__tui_browse_hists(session->evlist, help,
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index ec7b2405c377..9e2b0c44bed8 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -96,7 +96,8 @@ struct symbol_conf {
initialized,
kptr_restrict,
annotate_asm_raw,
- annotate_src;
+ annotate_src,
+ event_group;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/14] perf report: Add --group option
From: Namhyung Kim
Add --group option to enable event grouping. When enabled, all the
group members information will be shown together with the leader.
Cc: Jiri Olsa
Cc: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-report.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index f4d91bebd59d..b3e8fcb9bbce 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -171,6 +171,9 @@ OPTIONS
--objdump=::
Path to objdump binary.
+--group::
+ Show event group information together.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 50263ec0b0d0..9fb3e4bf49d6 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -668,6 +668,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Specify disassembler style (e.g. -M intel for intel
syntax)"),
OPT_BOOLEAN(0, "show-total-period", _conf.show_total_period,
"Show a column with the sum of periods"),
+ OPT_BOOLEAN(0, "group", _conf.event_group,
+ "Show event group information together"),
OPT_CALLBACK_NOOPT('b', "branch-stack", __branch_mode, "",
"use branch records for histogram filling",
parse_branch_mode),
OPT_STRING(0, "objdump", _path, "path",
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 14/14] perf report: Add report.group config option
From: Namhyung Kim
Add report.group config option for setting default value of event
group view. It affects the report output only if perf.data contains
event group info.
A user can write .perfconfig file like below to enable group view by
default:
$ cat ~/.perfconfig
[report]
group = true
And it can be disabled through command line:
$ perf report --no-group
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 9fb3e4bf49d6..40b61681c3d3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -8,6 +8,7 @@
#include "builtin.h"
#include "util/util.h"
+#include "util/cache.h"
#include "util/annotate.h"
#include "util/color.h"
@@ -54,6 +55,16 @@ struct perf_report {
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
+static int perf_report_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "report.group")) {
+ symbol_conf.event_group = perf_config_bool(var, value);
+ return 0;
+ }
+
+ return perf_default_config(var, value, cb);
+}
+
static int perf_report__add_branch_hist_entry(struct perf_tool *tool,
struct addr_location *al,
struct perf_sample *sample,
@@ -677,6 +688,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_END()
};
+ perf_config(perf_report_config, NULL);
+
argc = parse_options(argc, argv, options, report_usage, 0);
if (report.use_stdio)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/14] perf header: Ensure read/write finished successfully
From: Namhyung Kim
Use readn instead of read and check return value of do_write.
Suggested-by: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/util/header.c | 63 +++-
1 file changed, 36 insertions(+), 27 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index b7da4634a047..bb578d2d10f9 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -148,7 +148,7 @@ static char *do_read_string(int fd, struct perf_header *ph)
u32 len;
char *buf;
- sz = read(fd, , sizeof(len));
+ sz = readn(fd, , sizeof(len));
if (sz < (ssize_t)sizeof(len))
return NULL;
@@ -159,7 +159,7 @@ static char *do_read_string(int fd, struct perf_header *ph)
if (!buf)
return NULL;
- ret = read(fd, buf, len);
+ ret = readn(fd, buf, len);
if (ret == (ssize_t)len) {
/*
* strings are padded by zeroes
@@ -1051,16 +1051,25 @@ static int write_pmu_mappings(int fd, struct
perf_header *h __maybe_unused,
struct perf_pmu *pmu = NULL;
off_t offset = lseek(fd, 0, SEEK_CUR);
__u32 pmu_num = 0;
+ int ret;
/* write real pmu_num later */
- do_write(fd, _num, sizeof(pmu_num));
+ ret = do_write(fd, _num, sizeof(pmu_num));
+ if (ret < 0)
+ return ret;
while ((pmu = perf_pmu__scan(pmu))) {
if (!pmu->name)
continue;
pmu_num++;
- do_write(fd, >type, sizeof(pmu->type));
- do_write_string(fd, pmu->name);
+
+ ret = do_write(fd, >type, sizeof(pmu->type));
+ if (ret < 0)
+ return ret;
+
+ ret = do_write_string(fd, pmu->name);
+ if (ret < 0)
+ return ret;
}
if (pwrite(fd, _num, sizeof(pmu_num), offset) != sizeof(pmu_num)) {
@@ -1209,14 +1218,14 @@ read_event_desc(struct perf_header *ph, int fd)
size_t msz;
/* number of events */
- ret = read(fd, , sizeof(nre));
+ ret = readn(fd, , sizeof(nre));
if (ret != (ssize_t)sizeof(nre))
goto error;
if (ph->needs_swap)
nre = bswap_32(nre);
- ret = read(fd, , sizeof(sz));
+ ret = readn(fd, , sizeof(sz));
if (ret != (ssize_t)sizeof(sz))
goto error;
@@ -1244,7 +1253,7 @@ read_event_desc(struct perf_header *ph, int fd)
* must read entire on-file attr struct to
* sync up with layout.
*/
- ret = read(fd, buf, sz);
+ ret = readn(fd, buf, sz);
if (ret != (ssize_t)sz)
goto error;
@@ -1253,7 +1262,7 @@ read_event_desc(struct perf_header *ph, int fd)
memcpy(>attr, buf, msz);
- ret = read(fd, , sizeof(nr));
+ ret = readn(fd, , sizeof(nr));
if (ret != (ssize_t)sizeof(nr))
goto error;
@@ -1274,7 +1283,7 @@ read_event_desc(struct perf_header *ph, int fd)
evsel->id = id;
for (j = 0 ; j < nr; j++) {
- ret = read(fd, id, sizeof(*id));
+ ret = readn(fd, id, sizeof(*id));
if (ret != (ssize_t)sizeof(*id))
goto error;
if (ph->needs_swap)
@@ -1506,14 +1515,14 @@ static int perf_header__read_build_ids_abi_quirk(struct
perf_header *header,
while (offset < limit) {
ssize_t len;
- if (read(input, _bev, sizeof(old_bev)) != sizeof(old_bev))
+ if (readn(input, _bev, sizeof(old_bev)) != sizeof(old_bev))
return -1;
if (header->needs_swap)
perf_event_header__bswap(_bev.header);
len = old_bev.header.size - sizeof(old_bev);
- if (read(input, filename, len) != len)
+ if (readn(input, filename, len) != len)
return -1;
bev.header = old_bev.header;
@@ -1548,14 +1557,14 @@ static int perf_header__read_build_ids(struct
perf_header *header,
while (offset < limit) {
ssize_t len;
- if (read(input, , sizeof(bev)) != sizeof(bev))
+ if (readn(input, , sizeof(bev)) != sizeof(bev))
goto out;
if (header->needs_swap)
perf_event_header__bswap();
len = bev.header.size - sizeof(bev);
- if (read(input, filename, len) != len)
+ if (readn(input, filename, len) != len)
goto out;
/*
* The a1645ce1 changeset:
@@ -1641,7
[PATCH 12/14] perf report: Show group description when event group is enabled
From: Namhyung Kim
When using event group viewer, it's better to show the group
description rather than the leader information alone.
If a leader did not contain any member, it's a non-group event.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 15 +++
tools/perf/ui/browsers/hists.c | 25 +
tools/perf/ui/gtk/browser.c| 14 +++---
tools/perf/util/evsel.c| 25 +
tools/perf/util/evsel.h| 8
5 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index a1082d547150..50263ec0b0d0 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -299,6 +299,21 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*self,
char unit;
unsigned long nr_samples = self->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = self->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(self);
+ char buf[512];
+ size_t size = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, size);
+ evname = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, );
ret = fprintf(fp, "# Samples: %lu%c", nr_samples, unit);
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 69278b53667c..43e86eceb208 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1195,6 +1195,21 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size,
const struct thread *thread = hists->thread_filter;
unsigned long nr_samples = hists->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = hists->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ char buf[512];
+ size_t buflen = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, buflen);
+ ev_name = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, );
printed = scnprintf(bf, size,
@@ -1591,6 +1606,16 @@ static void perf_evsel_menu__write(struct ui_browser
*browser,
ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
HE_COLORSET_NORMAL);
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ ev_name = perf_evsel__group_name(evsel);
+
+ for_each_group_member(pos, evsel) {
+ nr_events +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ }
+ }
+
nr_events = convert_unit(nr_events, );
printed = scnprintf(bf, sizeof(bf), "%lu%c%s%s", nr_events,
unit, unit == ' ' ? "" : " ", ev_name);
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 2f1652b1bc05..5a1b4f29dd99 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -334,10 +334,18 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
const char *evname = perf_evsel__name(pos);
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ char buf[512];
+ size_t size = sizeof(buf);
- if (symbol_conf.event_group &&
- !perf_evsel__is_group_leader(pos))
- continue;
+ if (symbol_conf.event_group) {
+ if (!perf_evsel__is_group_leader(pos))
+ continue;
+
+ if (pos->nr_members > 1) {
+ perf_evsel__group_desc(pos, buf, size);
+ evname = buf;
+ }
+ }
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 7a2a3dc3ff03..c6922cdc5a0e 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -429,6 +429,31 @@ const char *perf_evsel__name(struct perf_evsel *evsel)
return evsel->name ?: "unknown";
}
+const char *perf_evsel__group_name(struct perf_evsel
[PATCH 00/14] perf report: Add support for event group view (v7)
Hi,
This is my 7th attempt to enable the event group view for perf report.
For basic idea and usage example, please see my initial post [1].
This version is rebased on the current acme/perf/core and Jiri's multi-
diff patchset [2] and addresses comments from the previous spin.
You can get this via 'perf/group-v7' branch on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Any comments are welcome, thanks,
Namhyung
v6 -> v7:
* hists__{match,link} changes are merged separately
* factor out inc_group_count() from parsing group_def (Jiri)
* add checking for group fields in evlist/evsel (Jiri)
* check return value of during header processing (Arnaldo)
* get rid of a temporal array in hpp functions (Arnaldo)
* convert hpp macros to static inline functions (Jiri)
v5 -> v6:
* set ->leader alse for leader evsel (Arnaldo)
* use hists__{match,link} (Arnaldo)
v4 -> v5:
* rebase onto acme/perf/core
v3 -> v4:
* patch 1-9 in previous post are merged.
* add Jiri's Acked-by
* add report.group config option
v2 -> v3:
* drop patch 1 since it's merged into acme/perf/core
* cherry-pick Jiri's hpp changes
* add missing bswap_32 on reading nr_groups (Jiri)
* remove perf_evlist__recalc_nr_groups() in favor of list_is_last (Jiri)
v1 -> v2:
* save group relation to header (Jiri)
[1] https://lkml.org/lkml/2012/7/24/81
[2] https://lkml.org/lkml/2012/12/13/144
Namhyung Kim (14):
perf tools: Keep group information
perf test: Add group test conditions
perf header: Ensure read/write finished successfully
perf header: Add HEADER_GROUP_DESC feature
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Add support for event group view
perf hist browser: Add support for event group view
perf gtk/browser: Add support for event group view
perf gtk/browser: Trim column header string when event group enabled
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 +++-
tools/perf/builtin-script.c | 12 --
tools/perf/tests/parse-events.c | 28 +++
tools/perf/ui/browsers/hists.c | 225
tools/perf/ui/gtk/browser.c | 131 +---
tools/perf/ui/hist.c | 353 +++
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 7 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 25 +++
tools/perf/util/evsel.h | 16 ++
tools/perf/util/header.c | 227 +---
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 59 +-
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/string.c | 18 ++
tools/perf/util/symbol.h | 3 +-
tools/perf/util/util.h | 1 +
22 files changed, 885 insertions(+), 290 deletions(-)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/14] perf hist browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Also move coloring logic into the hpp function so that each value can
be colored independently.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 159 -
tools/perf/ui/hist.c | 5 +-
2 files changed, 130 insertions(+), 34 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index d774efcc46d8..b467546ce7d4 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -567,25 +567,130 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
return row - first_row;
}
-#define HPP__COLOR_FN(_name, _field) \
-static int hist_browser__hpp_color_ ## _name( \
- struct perf_hpp_fmt *fmt __maybe_unused,\
- struct perf_hpp *hpp, \
- struct hist_entry *he) \
+struct hpp_arg {
+ struct ui_browser *b;
+ char folded_sign;
+ bool current_entry;
+};
+
+static int hist_browser__hpp_color_callchain(struct hpp_arg *arg)
+{
+ if (!symbol_conf.use_callchain)
+ return 0;
+
+ slsmg_printf("%c ", arg->folded_sign);
+ return 2;
+}
+
+static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *),
+ int (*callchain_cb)(struct hpp_arg *))
+{
+ int ret = 0;
+ double percent = 0.0;
+ struct hists *hists = he->hists;
+ struct hpp_arg *arg = hpp->ptr;
+
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
+
+ ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
+
+ if (callchain_cb)
+ ret += callchain_cb(arg);
+
+ ret += scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
+ slsmg_printf("%s", hpp->buf);
+
+ if (symbol_conf.event_group) {
+ int prev_idx, idx_delta, i;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
+
+ if (nr_members <= 1)
+ goto out;
+
+ prev_idx = perf_evsel__group_idx(evsel);
+
+ list_for_each_entry(pair, >pairs.head, pairs.node) {
+ u64 period = get_field(pair);
+ u64 total = pair->hists->stats.total_period;
+
+ if (!total)
+ continue;
+
+ evsel = hists_to_evsel(pair->hists);
+ idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
+
+ for (i = 0; i < idx_delta; i++) {
+ ui_browser__set_percent_color(arg->b, 0.0,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size,
+" %6.2f%%", 0.0);
+ slsmg_printf("%s", hpp->buf);
+ }
+
+ percent = 100.0 * period / total;
+ ui_browser__set_percent_color(arg->b, percent,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size,
+" %6.2f%%", percent);
+ slsmg_printf("%s", hpp->buf);
+
+ prev_idx += 1 + idx_delta;
+ }
+
+ idx_delta = nr_members - prev_idx - 1;
+
+ for (i = 0; i < idx_delta; i++) {
+ ui_browser__set_percent_color(arg->b, 0.0,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size, " %6.2f%%", 0.0);
+ slsmg_printf("%s", hpp->buf);
+ }
+ }
+out:
+ if (!arg->current_entry || !arg->b->navkeypressed)
+ ui_browser__set_color(arg->b, HE_COLORSET_NORMAL);
+
+ return ret;
+}
+
+static u64 __hpp_get_period(struct hist_entry *he)
+{
+ return he->stat.period;
+}
+
+static int hist_browser__hpp_color_overhead(struct perf_hpp_fmt *fmt
+ __maybe_unused,
+ struct perf_hpp *hpp,
+ struct hist_entry *he)
+{
+ return __hpp__color_fmt(hpp, he, __hpp_get_period,
+ hist_browser__hpp_color_callchain);
+}
+
[git pull] Input updates for 3.7-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. As usual, there are a couple of new drivers, input core now supports managed input devices (devres), a slew of drivers now have device tree support and a bunch of fixes and cleanups. There will be 2 conflicts: one in arch/arm/mach-ux500/board-mop500-stuib.c, and another in drivers/input/touchscreen/ti_tscadc.c (which was renamed into ti_am335x_tsc). Thanks! Changelog: - Aaro Koskinen (2): Input: i8042-io - fix up region handling on MIPS Input: add Retu power button driver. Alban Bedel (2): Input: tca8418_keypad - add support for device tree bindings Input: tca8418_keypad - add support for shared interrupt Alexander Shiyan (2): Input: remove Compaq iPAQ H3600 (Bitsy) touchscreen driver Input: gpio-keys-polled - honor 'autorepeat' setting in platform data Andreas Pretzsch (1): Input: imx_keypad - only set enabled columns to open-drain Andy Shevchenko (1): Input: ALPS - print small buffers via %*ph AnilKumar Ch (1): Input: matrix-keypad - add device tree support Ashish Jangam (1): Input: add DA9055 Onkey driver Bill Pemberton (6): Input: serio - remove CONFIG_HOTPLUG ifdefs Input: remove use of __devexit_p Input: remove use of __devinitdata Input: remove use of __devinitconst Input: remove use of __devinit Input: remove use of __devexit Deepak Sikri (1): Input: spear-keyboard - fix for balancing the enable_irq_wake Diego Calleja (1): Input: wacom - fix touch support for Bamboo Fun CTH-461 Dmitry Torokhov (15): Input: arc_ps2 - switch to using managed resources Input: fix sparse warning in multitouch code Input: fix sparse warning in __input_release_device() Input: introduce managed input devices (add devres support) Input: marix-keymap - automatically allocate memory for keymap OMAP: nokia770: remove custom implementation of ads7846_get_pendown_state Input: stmpe-keypad - add support for Device Tree bindings Input: gpio_keys - report initial state when opening the device Input: tca8418_keypad - use a temporary variable for parent device Input: tca8418_keypad - use dev_get_platdata() to retrieve platform data Input: tca8418_keypad - move device ID tables closer to where they are used Input: tca8418_keypad - increase severity of failures in probe() Input: tca8418-keypad - switch to using managed resources Input: gpio_keys - switch to using gpio_request_one() Input: gpio_keys_polled - switch to using gpio_request_one() Florian Fainelli (1): Input: matrix-keymap - provide a proper module license Guillermo A. Amaral (2): Input: xpad - minor formatting fixes Input: xpad - add a few new VID/PID combinations Henrik Rydberg (1): Input: document new members of struct input_dev Javier Martin (1): Input: qt2160 - fix qt2160_write() implementation Jonas Aaberg (1): Input: gpio_keys - disable hardware on suspend Kees Cook (2): Input: remove CONFIG_EXPERIMENTAL from keyboard drivers Input: remove CONFIG_EXPERIMENTAL from miscellaneous drivers Lee Jones (4): ARM: ux500: Strip out duplicate touch screen platform information Input: bu21013_ts - request regulator that actually exists Input: bu21013_ts - move GPIO init and exit functions into the driver Input: bu21013_ts - add support for Device Tree booting Mark Brown (3): Input: wm831x-ts - remove unneeded clearing of driver data Input: wm831x-ts - convert to devm_kzalloc() Input: wm831x-on - convert to devm_kzalloc() Mischa Jonker (1): Input: serio - add ARC PS/2 driver Peter Popovec (1): Input: walkera0701 - fix crash on startup Peter Ujfalusi (1): Input: twl4030-pwrbutton - switch to using TWL_MODULE_PM_MASTER define Ping Cheng (4): Input: wacom - clean up device type code Input: wacom - add support for 2 new multi-touch tablets (0x100 and 0x101) Input: wacom - simplify type check for newer V5 devices Input: wacom - add support for a new MT device (0x4001) Rolf Eike Beer (1): Input: HIL - remove one goto Sachin Kamat (1): Input: samsung-keypad - switch to using managed resources Sascha Hauer (1): Input: pwm-beeper - add devicetree probing support Shubhrajyoti D (1): Input: as5011 - use C99-style structure initializators Shubhrajyoti Datta (1): Input: cy8ctmg110_ts - use C99-style structure initializators Tomasz Figa (1): Input: mms114 - add device tree bindings Ulf Hansson (2): Input: nomadik-ske-keypad - fixup use of clk Input: nomadik-ske-keypad - start using the apb_pclk Vipul Kumar Samar (3): Input: stmpe-ts - initialize
[PATCH 4/4] ARM: tegra: Set SCU base address dynamically from DT
Set Snoop Control Unit(SCU) register base address dynamically from DT.
Signed-off-by: Hiroshi Doyu
---
arch/arm/mach-tegra/platsmp.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-tegra/platsmp.c b/arch/arm/mach-tegra/platsmp.c
index 1b926df..45c0b79 100644
--- a/arch/arm/mach-tegra/platsmp.c
+++ b/arch/arm/mach-tegra/platsmp.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -36,7 +38,7 @@
extern void tegra_secondary_startup(void);
-static void __iomem *scu_base = IO_ADDRESS(TEGRA_ARM_PERIF_BASE);
+static void __iomem *scu_base;
#define EVP_CPU_RESET_VECTOR \
(IO_ADDRESS(TEGRA_EXCEPTION_VECTORS_BASE) + 0x100)
@@ -143,14 +145,28 @@ done:
return status;
}
+static const struct of_device_id cortex_a9_scu_match[] __initconst = {
+ { .compatible = "arm,cortex-a9-scu", },
+ {}
+};
+
/*
* Initialise the CPU possible map early - this describes the CPUs
* which may be present or become present in the system.
*/
static void __init tegra_smp_init_cpus(void)
{
- unsigned int i, ncores = scu_get_core_count(scu_base);
+ struct device_node *np;
+ unsigned int i, ncores = 1;
+
+ np = of_find_matching_node(NULL, cortex_a9_scu_match);
+ if (!np)
+ return;
+ scu_base = of_iomap(np, 0);
+ if (!scu_base)
+ return;
+ ncores = scu_get_core_count(scu_base);
if (ncores > nr_cpu_ids) {
pr_warn("SMP: %u cores greater than maximum (%u), clipping\n",
ncores, nr_cpu_ids);
@@ -166,7 +182,8 @@ static void __init tegra_smp_init_cpus(void)
static void __init tegra_smp_prepare_cpus(unsigned int max_cpus)
{
tegra_cpu_reset_handler_init();
- scu_enable(scu_base);
+ if (scu_base)
+ scu_enable(scu_base);
}
struct smp_operations tegra_smp_ops __initdata = {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] ARM: dt: tegra30.dtsi: Add SCU node
Add Snoop Control Unit(SCU) node for Cortex A9 MP.
Signed-off-by: Hiroshi Doyu
---
arch/arm/boot/dts/tegra30.dtsip |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30.dtsip b/arch/arm/boot/dts/tegra30.dtsip
index 8feba6d..84a41c2 100644
--- a/arch/arm/boot/dts/tegra30.dtsip
+++ b/arch/arm/boot/dts/tegra30.dtsip
@@ -91,6 +91,11 @@
};
};
+ scu {
+ compatible = "arm,cortex-a9-scu";
+ reg = <0x5004 0x58>;
+ };
+
timer@50004600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x50040600 0x20>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] ARM: dt: tegra20.dtsi: Add SCU node
Add Snoop Control Unit(SCU) node for Cortex A9 MP.
Signed-off-by: Hiroshi Doyu
---
arch/arm/boot/dts/tegra20.dtsip |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsip b/arch/arm/boot/dts/tegra20.dtsip
index 3e046b1..d325aed 100644
--- a/arch/arm/boot/dts/tegra20.dtsip
+++ b/arch/arm/boot/dts/tegra20.dtsip
@@ -91,6 +91,11 @@
};
};
+ scu {
+ compatible = "arm,cortex-a9-scu";
+ reg = <0x5004 0x58>;
+ };
+
timer@50004600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x50040600 0x20>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] ARM: dt: Add doc for ARM Snoop Control Unit(SCU)
Add scu.txt under arm for ARM Snoop Control Unit(SCU)
Signed-off-by: Hiroshi Doyu
---
Documentation/devicetree/bindings/arm/scu.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/scu.txt
diff --git a/Documentation/devicetree/bindings/arm/scu.txt
b/Documentation/devicetree/bindings/arm/scu.txt
new file mode 100644
index 000..96264cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/scu.txt
@@ -0,0 +1,15 @@
+* ARM Snoop Control Unit(SCU)
+
+ARM cores often have a configurable SCU to the memory system through
+the AXI interfaces.
+
+Required properties:
+
+- compatible : "arm,cortex-a9-scu"
+- reg : Specifies base physical address and size of the SCU registers.
+
+Example:
+ scu {
+ compatible = "arm,cortex-a9-scu";
+ reg = <0x5004 0x58>;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin changes for 3.8
On Mon, Dec 17, 2012 at 2:04 PM, Bob Liu wrote:
>
> Hi linus,
>
Fix the lkml address, sorry.
> The following changes since commit 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>
> Linux 3.7 (2012-12-10 19:30:57 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin.git for-linus
>
> for you to fetch changes up to 86794b43569c9b8936dff2e8eed503393379af6e:
>
> blackfin: SEC: clean up SEC interrupt initialization (2012-12-14 11:20:22
> +0800)
>
>
> David Howells (1):
> UAPI: (Scripted) Disintegrate arch/blackfin/include/asm
>
> Lars-Peter Clausen (5):
> Blackfin: Annotate strncpy_from_user src parameter with __user
> Blackfin: Add missing __user annotations to put_user
> Blackfin: Annotate clear_user 'to' parameter with __user
> Blackfin: Annotate strnlen_user and strlen_user 'src' parameter with
> __user
> Blackfin: twi: Add missing __iomem annotation
>
> Sonic Zhang (3):
> blackfin: anomaly: add anomaly 1630 for bf5xx
> blackfin: kgdb: call generic_exec_single() directly
> blackfin: SEC: clean up SEC interrupt initialization
>
> Srinivas Kandagatla (1):
> Blackfin: dpmc: use module_platform_driver macro
>
> Steven Rostedt (1):
> blackfin: Use Kbuild infrastructure for kvm_para.h
>
> Tobias Klauser (2):
> Blackfin: remove unnecessary prototype for kobjsize()
> Blackfin: remove unused is_in_rom()
>
> arch/blackfin/include/asm/Kbuild |6 +-
> arch/blackfin/include/asm/bfin_sport.h | 128 +-
> arch/blackfin/include/asm/bfin_twi.h |2 +-
> arch/blackfin/include/asm/fixed_code.h | 30 +-
> arch/blackfin/include/asm/kvm_para.h |1 -
> arch/blackfin/include/asm/pgtable.h|2 -
> arch/blackfin/include/asm/ptrace.h | 161 +---
> arch/blackfin/include/asm/uaccess.h| 41 +-
> arch/blackfin/include/asm/unistd.h | 430 +--
> arch/blackfin/include/mach-common/irq.h|5 +-
> arch/blackfin/include/uapi/asm/Kbuild | 16 +
> arch/blackfin/include/uapi/asm/bfin_sport.h| 136 ++
> arch/blackfin/include/{ => uapi}/asm/byteorder.h |0
> arch/blackfin/include/{ => uapi}/asm/cachectl.h|0
> arch/blackfin/include/{ => uapi}/asm/fcntl.h |0
> arch/blackfin/include/uapi/asm/fixed_code.h| 38 ++
> arch/blackfin/include/{ => uapi}/asm/ioctls.h |0
> arch/blackfin/include/{ => uapi}/asm/poll.h|0
> arch/blackfin/include/{ => uapi}/asm/posix_types.h |0
> arch/blackfin/include/uapi/asm/ptrace.h| 170
> arch/blackfin/include/{ => uapi}/asm/sigcontext.h |0
> arch/blackfin/include/{ => uapi}/asm/siginfo.h |0
> arch/blackfin/include/{ => uapi}/asm/signal.h |0
> arch/blackfin/include/{ => uapi}/asm/stat.h|0
> arch/blackfin/include/{ => uapi}/asm/swab.h|0
> arch/blackfin/include/uapi/asm/unistd.h| 437
>
> arch/blackfin/kernel/kgdb.c| 13 +-
> arch/blackfin/mach-bf518/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf527/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf533/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf537/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf538/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf548/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf561/include/mach/anomaly.h|1 +
> arch/blackfin/mach-bf609/include/mach/irq.h|3 -
> arch/blackfin/mach-bf609/pm.c |3 +-
> arch/blackfin/mach-common/dpmc.c | 19 +-
> arch/blackfin/mach-common/ints-priority.c | 272 ++--
> 38 files changed, 972 insertions(+), 948 deletions(-)
> delete mode 100644 arch/blackfin/include/asm/kvm_para.h
> create mode 100644 arch/blackfin/include/uapi/asm/bfin_sport.h
> rename arch/blackfin/include/{ => uapi}/asm/byteorder.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/cachectl.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/fcntl.h (100%)
> create mode 100644 arch/blackfin/include/uapi/asm/fixed_code.h
> rename arch/blackfin/include/{ => uapi}/asm/ioctls.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/poll.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/posix_types.h (100%)
> create mode 100644 arch/blackfin/include/uapi/asm/ptrace.h
> rename arch/blackfin/include/{ => uapi}/asm/sigcontext.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/siginfo.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/signal.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/stat.h (100%)
> rename arch/blackfin/include/{ => uapi}/asm/swab.h
Re: [GIT PULL] fbdev changes for 3.8
On Sun, Dec 16, 2012 at 12:35:37PM -0800, Tony Lindgren wrote: > * Tony Lindgren [121216 09:49]: > > * Dave Jones [121215 14:27]: > > > On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote: > > > > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen > > > wrote: > > > > > Hi Linus, > > > > > > > > > > Florian, the fbdev maintainer, has been very busy lately, so I > > > offered to send > > > > > the pull request for fbdev for this merge window. > > > > > > > > Pulled. However, with this I get the Kconfig question > > > > > > > >OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW) > > > > > > > > which doesn't make a whole lot of sense on x86-64, unless there's > > > > something about OMAP2 that I don't know. > > > > > > > > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at > > > > least ARM. Because showing it to anybody else seems insane. > > > > > > > > Same goes for FB_OMAP2 for that matter. I realize that it's likely > > > > nice to get compile testing for this on x86-64 too, but if that's the > > > > intent, we need to think about it some more. I don't think it's good > > > > to ask actual normal users questions like this just for compile > > > > coverage. > > > > > > This OMAP stuff has been creeping into x86 builds for a while. > > > Grep from my current build config .. > > > > > > # CONFIG_OMAP_OCP2SCP is not set > > > # CONFIG_KEYBOARD_OMAP4 is not set > > > # CONFIG_OMAP2_DSS is not set > > > # CONFIG_OMAP_USB2 is not set > > > > > > There was some other arm-ism that does the same that I' currently > > > forgetting, > > > or maybe that got fixed.. > > > > Those are all omap internal devices and should be all marked with > > depends on ARCH_OMAP2PLUS. > > > > It's a different story for external devices that may be used on other > > architectures. > > > > I only came up with one reason to compile internal devices for other > > architectures: In some cases the driver subsystem maintainer may want to > > be able to compile test subsystem wide changes without having to compile > > for each target separately. But for those cases it's trivial to carry a > > compile test patch that just drops the depends Kconfig entries. > > And here's a patch to limit the omap drivers above to omap only. Do you think we could add a new symbol to debug options, something like COMPILE_COVERAGE, and have drivers that can be compiled on platforms other than ones having the hardware to do depend on ARCH_XXX || COMPILE_CONVERAGE This way people who want to do compile coverage do not have to carry patches and allyesconfig will pick this right up. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mfd: tps65910: Select REGMAP_IRQ in Kconfig to fix build error
On Mon, Dec 10, 2012 at 16:44:56, AnilKumar, Chimata wrote: > TPS65910 mfd driver uses functions that are only avaiable when > REGMAP_IRQ is enabled. So "select REGMAP_IRQ" is added to mfd > Kconfig to fix below build error: > > drivers/built-in.o: In function `tps65910_irq_exit': > /media/anil/kernel/drivers/mfd/tps65910.c:265: undefined reference to > `regmap_del_irq_chip' > drivers/built-in.o: In function `tps65910_irq_init': > /media/anil/kernel/drivers/mfd/tps65910.c:254: undefined reference to > `regmap_add_irq_chip' > drivers/built-in.o: In function `tps65910_i2c_probe': > /media/anil/kernel/drivers/mfd/tps65910.c:509: undefined reference to > `regmap_irq_get_domain' > make: *** [vmlinux] Error 1 > > Signed-off-by: AnilKumar Ch > --- > drivers/mfd/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 1c0abd4..01413a2 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -237,6 +237,7 @@ config MFD_TPS65910 > depends on I2C=y && GPIOLIB > select MFD_CORE > select REGMAP_I2C > + select REGMAP_IRQ > select IRQ_DOMAIN > help > if you say yes here you get support for the TPS65910 series of Hi Samuel, If there are no comments on this patch could you please pull? Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] CLK: uninline clk_prepare_enable() and clk_disable_unprepare()
Hi Viresh, On Sun, Dec 16, 2012 at 06:35:24PM +0530, Viresh Kumar wrote: > On 16 December 2012 18:10, Russell King - ARM Linux > wrote: > > Well, there's my comment against patch 2 which never got a reply: > > > > "Again, what about stuff not using drivers/clk/clk.c ?" > > > > Has this been addressed? > > Hmm.. I misread it and thought it is same as breaking other platforms > because there are > no dummy routines. But i was wrong :( > > So, the problem is, platform not using common-clock framework uses > this routine, and they > don't want it to be dummy but call prepare & enable.. > > Because Dmirty requires this one to be non-inline, either he can move > these routines to > drivers/clk/clk-devres.c (which would be wrong) or can add wrappers > over them in clk-devres > file. They do not _have_ to be non-inline, I think we should simply drop the first 2 patches and I will refresh and ressend the 3rd one. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PCI: Set root bridge ACPI handle in advance
On Sun, Dec 16, 2012 at 2:25 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The ACPI handles of PCI root bridges need to be known to > acpi_bind_one(), so that it can create the appropriate > "firmware_node" and "physical_node" files for them, but currently > the way it gets to know those handles is not exactly straightforward > (to put it lightly). > > This is how it works, roughly: > > 1. acpi_bus_scan() finds the handle of a PCI root bridge, > creates a struct acpi_device object for it and passes that > object to acpi_pci_root_add(). > > 2. acpi_pci_root_add() creates a struct acpi_pci_root object, > populates its "device" field with its argument's address > (device->handle is the ACPI handle found in step 1). > > 3. The struct acpi_pci_root object created in step 2 is passed > to pci_acpi_scan_root() and used to get resources that are > passed to pci_create_root_bus(). > > 4. pci_create_root_bus() creates a struct pci_host_bridge object > and passes its "dev" member to device_register(). > > 5. platform_notify(), which for systems with ACPI is set to > acpi_platform_notify(), is called. > > So far, so good. Now it starts to be "interesting". > > 6. acpi_find_bridge_device() is used to find the ACPI handle of > the given device (which is the PCI root bridge) and executes > acpi_pci_find_root_bridge(), among other things, for the > given device object. > > 7. acpi_pci_find_root_bridge() uses the name (sic!) of the given > device object to extract the segment and bus numbers of the PCI > root bridge and passes them to acpi_get_pci_rootbridge_handle(). > > 8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI > root bridges and finds the one that matches the given segment > and bus numbers. Its handle is then used to initialize the > ACPI handle of the PCI root bridge's device object by > acpi_bind_one(). However, this is *exactly* the ACPI handle we > started with in step 1. > > Needless to say, this is quite embarassing, but it may be avoided > thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be > initialized in advance), which makes it possible to initialize the > ACPI handle of a device before passing it to device_register(). > Namely, if pci_acpi_scan_root() could easily pass the root bridge's > ACPI handle to pci_create_root_bus(), the latter could set the ACPI > handle in its struct pci_host_bridge object's "dev" member before > passing it to device_register() and steps 6-8 above wouldn't be > necessary any more. > > To make that happen I decided to repurpose the 4th argument of > pci_create_root_bus(), because that allowed me to avoid defining > additional callbacks or similar things and didn't seem to impact > architectures without ACPI substantially. > > Only x86 and ia64 are affected directly, there should be no > functional changes resulting from this on other architectures. that is good one to avoid that find_root_bridge... > > Signed-off-by: Rafael J. Wysocki > --- > > Should apply to the current Linus' tree, boots correctly on x86(-64). > > Thanks, > Rafael > > --- > arch/ia64/pci/pci.c |5 - > arch/powerpc/kernel/pci-common.c |3 ++- > arch/sparc/kernel/pci.c |3 ++- > arch/x86/pci/acpi.c |5 - > drivers/acpi/pci_root.c | 18 -- > drivers/pci/pci-acpi.c | 19 --- > drivers/pci/probe.c | 16 +++- > include/acpi/acpi_bus.h |1 - > include/linux/pci.h |9 - > 9 files changed, 31 insertions(+), 48 deletions(-) you need to update other arch for pci_create_root_bus arch/powerpc/kernel/pci-common.c: bus = pci_create_root_bus(hose->parent, hose->first_busno, arch/s390/pci/pci.c:zdev->bus = pci_create_root_bus(NULL, ZPCI_BUS_NR, _root_ops, arch/sparc/kernel/pci.c:bus = pci_create_root_bus(parent, pbm->pci_first_busno, pbm->pci_ops, drivers/parisc/dino.c: dino_dev->hba.hba_bus = bus = pci_create_root_bus(>dev, drivers/parisc/lba_pci.c: pci_create_root_bus(>dev, lba_dev->hba.bus_num.start, > > Index: linux/arch/x86/pci/acpi.c > === > --- linux.orig/arch/x86/pci/acpi.c > +++ linux/arch/x86/pci/acpi.c > @@ -450,6 +450,7 @@ struct pci_bus * __devinit pci_acpi_scan > LIST_HEAD(resources); > struct pci_bus *bus = NULL; > struct pci_sysdata *sd; > + struct pci_root_sys_info si; > int node; > #ifdef CONFIG_ACPI_NUMA > int pxm; > @@ -486,6 +487,8 @@ struct pci_bus * __devinit pci_acpi_scan > sd = >sd; > sd->domain = domain; > sd->node = node; > + si.acpi_node.handle = device->handle; > + si.sysdata = sd; maybe you can try to have si.acpi_handle directly ? Yinghai -- To unsubscribe from this list:
Re: [PATCH 00/14] perf, diff: multiple perf.data file support
Hi Jiri, On Thu, 13 Dec 2012 14:08:58 +0100, Jiri Olsa wrote: > hi, > adding support to display diff for more than 2 perf.data files. > > The basic idea is describe in the initial RFC in here: > https://lkml.org/lkml/2012/11/28/200 > > It's rebased on current Arnaldo's perf core with Namhyung's > changes. For the whole series: Reviewed-by: Namhyung Kim Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] perf changes for v3.8
On 12/13/12 10:31 AM, Ingo Molnar wrote:
* Linus Torvalds wrote:
So the default shouldn't necessarily be "include guest". The default
should presumably be "the user didn't say", and then the kernel does
whatever works best.
If the user actually explicitly says one or the other, we should try
to honor that (and then EOPNOTSUPP may be a "sorry, I really cannot do
that particular combination that you explicitly asked for").
That should make everybody happy. Doing a non-PEBS virtualized perf
run should still work with the old binary.
So there should be two bits: "include guest" (V in the event specifier
unless you already used that for something else) and "host only" (H),
and they should both default to off. Then the kernel can see the three
actual cases.
(Or four cases, if you really want to: you may or may not want to make
the "both V and H set means both, and _only_ V set means 'no host at
all, _only_ virtual environment'. So then ":ppV" would mean
"cycle-accurate for virtual box _only_", while ":ppVH" would mean
"cycle-accurate for both the host and the virtual box". Of course,
considering the PEBS interface, right now neither of those can
actually work, but plain ":V" and ":HV" could work).
The important thing, I think, is that if the user doesn't know
or care about the VM case (because he's not running any!) and
doesn't specify, then the kernel should not say EOPNOTSUPP,
and should do whatever works for that cpu.
Agreed.
David, wanna send a patch for this?
As I mentioned in a prior email exclude_{guest,host} work currently work
fine without PEBS. The current matrix for the flags:
profiling
guesthost
-e yy
-e :G yn- G means enable guest, turn off host
-e :H ny- H means enable host, turn off guest
-e :GH yy- G followed by H means enable both
-e :HG yy- same as GH
There is no reason to change how these work. It's the variants with :p
that need to be handled:
-e :p ny- guest off is required
-e :pG yn- needs to fail - not supported
-e :pH ny
-e :pGH yy- needs to fail - not supported
This is the logic that was implemented in the original patchset which
was pulled into v3.7 and the cause of this email thread.
One suggestion was to switch exclude_guest to include_guest. I take that
to mean deprecate the current exclude_guest and add a new include_guest
flag. Given that there are a number of exclude_ flags ( = user,
kernel, host, guest, hv, etc) that would make the perf code inconsistent.
All that is needed is for the current exclude_guest flag to be
deprecated such that for older binaries on newer kernels it is ignored
(perhaps a warn on once), and then a new flag -- exclude_guest2 -- is
then used for the new logic.
e.g.,
diff --git a/include/uapi/linux/perf_event.h
b/include/uapi/linux/perf_event.h
index 4f63c05..19900df 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -266,12 +266,14 @@ struct perf_event_attr {
sample_id_all : 1, /* sample_type all events */
exclude_host : 1, /* don't count in host */
- exclude_guest : 1, /* don't count in guest */
+ exclude_guest : 1, /* don't count in guest - DEPRECATED */
exclude_callchain_kernel : 1, /* exclude kernel
callchains */
exclude_callchain_user : 1, /* exclude user callchains */
- __reserved_1 : 41;
+ exclude_guest2 : 1, /* don't count in guest */
+
+ __reserved_1 : 40;
union {
__u32 wakeup_events;/* wakeup every n events */
Do you agree with that?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.8
Linus Torvalds writes: > On Sat, Dec 15, 2012 at 12:28 AM, James Morris wrote: >> A quiet cycle for the security subsystem with just a few maintenance >> updates. > > Ok, pulled. There were a few trivial conflicts (mostly due to some of > the key allocation patches having already been merged, and some of the > kuid/kgid changes due to the userns changes). > > I'd like you to double-check the end result, but it *looks* fine. > Adding both EricB and DavidH to the participants since the conflicts > were generally due to intetractions with their patches. I just read through the conflict resolution and I don't see any kuid/kgid problems. I am surprised that there were any kuid/kgid conflicts as all of my changes in that area were in 3.6-rc1. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 17
Hi all, Changes since 20121214: Lots of conflicts are migrating between trees. The btrfs tree gained a build failure so I used the version from next-20121214. The akpm tree lost a commit that turned up elsewhere. I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 214 trees (counting Linus' and 28 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (11520e5 Revert "x86-64/efi: Use EFI to deal with platform wall clock (again)") Merging fixes/master (8041853 disable the SB105X driver) Merging kbuild-current/rc-fixes (bad9955 menuconfig: Replace CIRCLEQ by list_head-style lists.) Merging arm-current/fixes (dad5451 ARM: 7605/1: vmlinux.lds: Move .notes section next to the rodata) Merging m68k-current/for-linus (5fec45a m68k/sun3: Fix instruction faults) Merging powerpc-merge/merge (e716e01 powerpc/eeh: Do not invalidate PE properly) Merging sparc/master (66cdd0c Merge tag 'kvm-3.8-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm) Merging net/master (df48419 ipv6: Fix Makefile offload objects) Merging sound-current/for-linus (d846b17 ALSA: hda - Fix build without CONFIG_PM) Merging pci-current/for-linus (ff8e59b PCI/portdrv: Don't create hotplug slots unless port supports hotplug) Merging wireless/master (eca2a43 bridge: fix icmpv6 endian bug and other sparse warnings) Merging driver-core.current/driver-core-linus (d42b3a2 Merge branch 'core-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging tty.current/tty-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging usb.current/usb-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging staging.current/staging-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging char-misc.current/char-misc-linus (1ebaf4f Merge branch 'x86-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging input-current/for-linus (e12b3ce Input: wacom - fix touch support for Bamboo Fun CTH-461) Merging md-current/for-linus (749586b md/raid5: use async_tx_quiesce() instead of open-coding it.) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (a2c0911 crypto: caam - Updated SEC-4.0 device tree binding for ERA information.) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (03a0b4c solos-pci: fix double-free of TX skb in DMA mode) CONFLICT (content): Merge conflict in arch/x86/Kconfig.cpu CONFLICT (content): Merge conflict in arch/x86/Kconfig CONFLICT (content): Merge conflict in arch/powerpc/Kconfig Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d271c Linux 3.6) Merging devicetree-current/devicetree/merge (0e622d3 of/address: sparc: Declare of_iomap as an extern function for sparc again) Merging spi-current/spi/merge (a0d271c Linux 3.6) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging
Re: linux-next: build failure after merge of the btrfs tree
On Sun, Dec 16, 2012 at 08:13:55PM -0700, Stephen Rothwell wrote: > Hi Chris, > > On Sun, 16 Dec 2012 21:52:41 -0500 Chris Mason > wrote: > > > > On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote: > > > On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote: > > > Josef and I have sob on all of our commits (at least all the ones not in > > > 3.7, I didn't go back farther). In this case the Author was Stefan and > > > it ended up rebased in either Josef's or my tree. We usually try to > > > preserve merges on rebase, but this time was a bigger set of changes > > > than usual and it didn't work out. > > > > Just FYI, I've pushed out a fixed version of the tree with proper > > signed-off-by on all the commits, thanks for catching that. > > > > It also has the fix for the ppc compile problems. (This isn't a pull > > request yet, I've got the hash collision fix and a few others pending as > > well). > > You do realise that I just fetch your tree/branch each day, right? So it > will be in tomorrow's linux-next. Yes, but I had pushed to that for-linus branch for Stefan to more easily see the changes, and I wanted to make it clear I had just redone things for the signed-off-by. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build warning after merge of the final tree
Hi all,
On Mon, 17 Dec 2012 14:22:38 +1100 Stephen Rothwell
wrote:
>
> After merging the final tree, today's linux-next build (powerpc allnoconfig)
> produced this warning:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> (HAVE_GENERIC_HARDIRQS && (IRQ_DOMAIN && DEBUG_FS || MAY_HAVE_SPARSE_IRQ))
>
> I don't know what introduced that.
Actually probably caused by commit a1eaa3bc8247 ("Kconfig: fix Irq
Subsystem menu") from the akpm tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp1vjyQaYmwh.pgp
Description: PGP signature
Re: [PATCH v2] mm: Downgrade mmap_sem before locking or populating on mmap
On Sun, Dec 16, 2012 at 10:05 AM, Andy Lutomirski wrote: > On Sun, Dec 16, 2012 at 4:39 AM, Michel Lespinasse wrote: >> My main concern is that just downgrading the mmap_sem only hides the >> problem: as soon as a writer gets queued on that mmap_sem, >> reader/writer fairness kicks in and blocks any new readers, which >> makes the problem reappear. So in order to completely fix the issue, >> we should look for a way that doesn't require holding the mmap_sem >> (even in read mode) for the entire duration of the populate or mlock >> operation. > > Ugh. > > At least with my patch, mmap in MCL_FUTURE mode is no worse than mmap > + mlock. I suspect I haven't hit this because all my mmaping is done > by one thread, so it never ends up waiting for itself, and the other > thread have very short mmap_sem hold times. Yes, you won't hit the problems with long read-side mmap_sem hold times if you don't have other threads blocking for the write side. >> I think this could be done by extending the mlock work I did as part >> of v2.6.38-rc1. The commit message for >> c explains the idea; basically >> mlock() was split into do_mlock() which just sets the VM_LOCKED flag >> on vmas as needed, and do_mlock_pages() which goes through a range of >> addresses and actually populates/mlocks each individual page that is >> part of a VM_LOCKED vma. > > Doesn't this have the same problem? It holds mmap_sem for read for a > long time, and if another writer comes in then r/w starvation > prevention will kick in. Well, my point is that do_mlock_pages() doesn't need to hold the mmap_sem read side for a long time. It currently releases it when faulting a page requires a disk read, and could conceptually release it more often if needed. We can't easily release mmap_sem from within mmap_region() since mmap_region's callers don't expect it; however we can defer the page mlocking and we don't have to hold mmap_sem continuously until then. The only constraints are the new VM_LOCKED region's pages must be mlocked before we return to userspace, and that if a concurrent thread modifies the mappings while we don't hold mmap_sem, and creates a new non-mlocked region, we shouldn't mlock those pages in do_mlock_pages(). -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the final tree
Hi all, After merging the final tree, today's linux-next build (powerpc allnoconfig) produced this warning: warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && (IRQ_DOMAIN && DEBUG_FS || MAY_HAVE_SPARSE_IRQ)) I don't know what introduced that. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLGWnWpsV35.pgp Description: PGP signature
Re: linux-next: build failure after merge of the btrfs tree
Hi Chris, On Sun, 16 Dec 2012 21:52:41 -0500 Chris Mason wrote: > > On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote: > > On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote: > > Josef and I have sob on all of our commits (at least all the ones not in > > 3.7, I didn't go back farther). In this case the Author was Stefan and > > it ended up rebased in either Josef's or my tree. We usually try to > > preserve merges on rebase, but this time was a bigger set of changes > > than usual and it didn't work out. > > Just FYI, I've pushed out a fixed version of the tree with proper > signed-off-by on all the commits, thanks for catching that. > > It also has the fix for the ppc compile problems. (This isn't a pull > request yet, I've got the hash collision fix and a few others pending as > well). You do realise that I just fetch your tree/branch each day, right? So it will be in tomorrow's linux-next. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpUbVv9FlGbc.pgp Description: PGP signature
Re: [RFC PATCH v2 3/6] sched: pack small tasks
>
> CPU is a bug that slipped into domain degeneration. You should have
> SIBLING/MC/NUMA (chasing that down is on todo).
Uh, the SD_PREFER_SIBLING on cpu domain is recovered by myself for a share
memory benchmark regression. But consider all the situations, I think the
flag is better to be removed.
>From 96bee9a03b2048f2686fbd7de0e2aee458dbd917 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Mon, 17 Dec 2012 09:42:57 +0800
Subject: [PATCH 01/18] sched: remove SD_PERFER_SIBLING flag
The flag was introduced in commit b5d978e0c7e79a. Its purpose seems
trying to fullfill one node first in NUMA machine via pulling tasks
from other nodes when the node has capacity.
Its advantage is when few tasks share memories among them, pulling
together is helpful on locality, so has performance gain. The shortage
is it will keep unnecessary task migrations thrashing among different
nodes, that reduces the performance gain, and just hurt performance if
tasks has no memory cross.
Thinking about the sched numa balancing patch is coming. The small
advantage are meaningless to us, So better to remove this flag.
Reported-by: Mike Galbraith
Signed-off-by: Alex Shi
---
include/linux/sched.h| 1 -
include/linux/topology.h | 2 --
kernel/sched/core.c | 1 -
kernel/sched/fair.c | 19 +--
4 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5dafac3..6dca96c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -836,7 +836,6 @@ enum cpu_idle_type {
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing
instance */
#define SD_ASYM_PACKING0x0800 /* Place busy groups earlier in
the domain */
-#define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling
domain */
#define SD_OVERLAP 0x2000 /* sched_domains of this level overlap
*/
extern int __weak arch_sd_sibiling_asym_packing(void);
diff --git a/include/linux/topology.h b/include/linux/topology.h
index d3cf0d6..15864d1 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -100,7 +100,6 @@ int arch_update_cpu_topology(void);
| 1*SD_SHARE_CPUPOWER \
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE\
- | 0*SD_PREFER_SIBLING \
| arch_sd_sibling_asym_packing()\
, \
.last_balance = jiffies, \
@@ -162,7 +161,6 @@ int arch_update_cpu_topology(void);
| 0*SD_SHARE_CPUPOWER \
| 0*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE\
- | 1*SD_PREFER_SIBLING \
, \
.last_balance = jiffies, \
.balance_interval = 1,\
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 5dae0d2..8ed2784 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6014,7 +6014,6 @@ sd_numa_init(struct sched_domain_topology_level *tl, int
cpu)
| 0*SD_SHARE_CPUPOWER
| 0*SD_SHARE_PKG_RESOURCES
| 1*SD_SERIALIZE
- | 0*SD_PREFER_SIBLING
| sd_local_flags(level)
,
.last_balance = jiffies,
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 59e072b..5d175f2 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4339,13 +4339,9 @@ static bool update_sd_pick_busiest(struct lb_env *env,
static inline void update_sd_lb_stats(struct lb_env *env,
int *balance, struct sd_lb_stats *sds)
{
- struct sched_domain *child = env->sd->child;
struct sched_group *sg = env->sd->groups;
struct sg_lb_stats sgs;
- int load_idx, prefer_sibling = 0;
-
- if (child && child->flags & SD_PREFER_SIBLING)
- prefer_sibling = 1;
+ int load_idx;
load_idx = get_sd_load_idx(env->sd, env->idle);
@@ -4362,19 +4358,6 @@ static inline void update_sd_lb_stats(struct lb_env *env,
sds->total_load += sgs.group_load;
sds->total_pwr += sg->sgp->power;
- /*
-* In case the child domain prefers tasks go to siblings
-
Re: [PATCH/WIP/RFC 02/14] shmobile-iommu: Move IPMMU driver to drivers/iommu
Hi Laurent, On 2012/12/17 2:25, Laurent Pinchart wrote: > Signed-off-by: Laurent Pinchart > --- > arch/arm/mach-shmobile/Kconfig |6 -- > arch/arm/mach-shmobile/Makefile|3 --- > drivers/iommu/Kconfig |6 ++ > drivers/iommu/Makefile |1 + > .../ipmmu.c => drivers/iommu/shmobile-ipmmu.c |0 > 5 files changed, 7 insertions(+), 9 deletions(-) > rename arch/arm/mach-shmobile/ipmmu.c => drivers/iommu/shmobile-ipmmu.c > (100%) I agree that arch/arm is not a good place, but I'm not completely sure that ipmmu.c belongs in drivers/iommu. The reason is because of the PMB functionality provided by the IPMMU. The PMB provides a fixed address remapping capability that is completely unrelated to the IOMMU functionality. Since this remapping is done by writing the IPMMU registers directly, instead of via a page table it doesn't really fit in well with the IOMMU API (it also supports things like tiled/linear address translation, which require some other method to set up). Since the PMB and the IOMMU functions of the IPPMU share the same register address space, we would like to have one driver to handle the register accesses of both of these functions. That driver is ipmmu.c. So if ipmmu.c is in drivers/iommu, the entire IOMMU subsystem must be enabled in order to use the PMB functionality. So maybe it might be better to treat the IPMMU like a multifuction device, with a core driver (ipmmu.c) in one location and the function implementations in their own respective directories. Does drivers/mfd sound like a good place for it? Thanks, Damian. -- Damian Hobson-Garcia IGEL Co.,Ltd http://www.igel.co.jp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix kernel BUG at huge_memory.c:1474!
On Sun, Dec 16, 2012 at 6:56 PM, Hugh Dickins wrote:
> Andrea's autonuma-benchmark numa01 hits kernel BUG at huge_memory.c:1474!
> in change_huge_pmd called from change_protection from change_prot_numa
> from task_numa_work.
>
> That BUG, introduced in the huge zero page commit cad7f613c4d0 ("thp:
> change_huge_pmd(): make sure we don't try to make a page writable")
> was trying to verify that newprot never adds write permission to an
> anonymous huge page; but Automatic NUMA Balancing's 4b10e7d562c9 ("mm:
> mempolicy: Implement change_prot_numa() in terms of change_protection()")
> adds a new prot_numa path into change_huge_pmd(), which makes no use of
> the newprot provided, and may retain the write bit in the pmd.
Ok. I did wonder about that particular conflict, but it looked like
neither case was writable, so I resolved it wrongly, and it worked for
me, but then I don't have any numa setups, nor do I even enable it..
Thanks,
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [char-misc for 3.8] mei: avoid oops in watchdog unregister code path
On 12/16/2012 07:23 PM, Tomas Winkler wrote:
> With commit c7d3df3 "mei: use internal watchdog device registration
> tracking" will crash the kernel on shutdown path on systems
> where ME watchdog is not present.
> Since the watchdog was never initialized in such case
> the WDOG_UNREGISTERED bit is never set and the system
> crashes on access to uninitialized variables down the path.
>
> To solve the issue we query for NULL on watchdog driver driver_data
> to check whether the device is registered. This is handled in the
> driver and doesn't depend on watchdog core internals.
>
> Cc: Borislav Petkov
> Cc: Wanlong Gao
> Signed-off-by: Jerry Snitselaar
> Signed-off-by: Tomas Winkler
Fixed the panic here, thank you.
Tested-by: Wanlong Gao
> ---
> drivers/misc/mei/wd.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/misc/mei/wd.c b/drivers/misc/mei/wd.c
> index 636409f..9299a8c 100644
> --- a/drivers/misc/mei/wd.c
> +++ b/drivers/misc/mei/wd.c
> @@ -370,7 +370,7 @@ void mei_watchdog_register(struct mei_device *dev)
>
> void mei_watchdog_unregister(struct mei_device *dev)
> {
> - if (test_bit(WDOG_UNREGISTERED, _wd_dev.status))
> + if (watchdog_get_drvdata(_wd_dev) == NULL)
> return;
>
> watchdog_set_drvdata(_wd_dev, NULL);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: fix kernel BUG at huge_memory.c:1474!
Andrea's autonuma-benchmark numa01 hits kernel BUG at huge_memory.c:1474!
in change_huge_pmd called from change_protection from change_prot_numa
from task_numa_work.
That BUG, introduced in the huge zero page commit cad7f613c4d0 ("thp:
change_huge_pmd(): make sure we don't try to make a page writable")
was trying to verify that newprot never adds write permission to an
anonymous huge page; but Automatic NUMA Balancing's 4b10e7d562c9 ("mm:
mempolicy: Implement change_prot_numa() in terms of change_protection()")
adds a new prot_numa path into change_huge_pmd(), which makes no use of
the newprot provided, and may retain the write bit in the pmd.
Just move the BUG_ON(pmd_write(entry)) up into the !prot_numa block.
Signed-off-by: Hugh Dickins
---
mm/huge_memory.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- 2a74dbb9/mm/huge_memory.c 2012-12-16 16:35:08.752441527 -0800
+++ linux/mm/huge_memory.c 2012-12-16 18:21:24.308156970 -0800
@@ -1460,9 +1460,10 @@ int change_huge_pmd(struct vm_area_struc
if (__pmd_trans_huge_lock(pmd, vma) == 1) {
pmd_t entry;
entry = pmdp_get_and_clear(mm, addr, pmd);
- if (!prot_numa)
+ if (!prot_numa) {
entry = pmd_modify(entry, newprot);
- else {
+ BUG_ON(pmd_write(entry));
+ } else {
struct page *page = pmd_page(*pmd);
/* only check non-shared pages */
@@ -1471,7 +1472,6 @@ int change_huge_pmd(struct vm_area_struc
entry = pmd_mknuma(entry);
}
}
- BUG_ON(pmd_write(entry));
set_pmd_at(mm, addr, pmd, entry);
spin_unlock(>vm_mm->page_table_lock);
ret = 1;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Automatic NUMA Balancing V11
On Sun, 16 Dec 2012, Linus Torvalds wrote: > On Wed, Dec 12, 2012 at 2:03 AM, Mel Gorman wrote: > > This is a pull request for "Automatic NUMA Balancing V11". The list > > Ok, guys, I've pulled this and pushed out. There were some conflicts > with both the VM changes and with the scheduler tree, but they were > pretty small and looked simple, so I fixed them up and hope they all > work. Great! Thank you. Rejoicing on all sides. One small merge fixup follows under new subject. Hugh > > Has anybody tested the impact on single-node systems? If distros > enable this by default (and it does have 'default y', which is a big > no-no for new features - I undid that part) then there will be tons of > people running this without actually having multiple sockets. Does it > gracefully avoid pointless overheads for this case? > > Anyway, hopefully we'll have a more real numa balancing for 3.9, and > this is still considered a reasonable base for that work. > > Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the btrfs tree
On Sun, Dec 16, 2012 at 05:15:04PM -0700, Chris Mason wrote: > On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote: > Josef and I have sob on all of our commits (at least all the ones not in > 3.7, I didn't go back farther). In this case the Author was Stefan and > it ended up rebased in either Josef's or my tree. We usually try to > preserve merges on rebase, but this time was a bigger set of changes > than usual and it didn't work out. Just FYI, I've pushed out a fixed version of the tree with proper signed-off-by on all the commits, thanks for catching that. It also has the fix for the ppc compile problems. (This isn't a pull request yet, I've got the hash collision fix and a few others pending as well). -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PART4 Patch v2 2/2] memory_hotplug: allow online/offline memory to result movable node
Hi Andrew,
So sorry for such a long delay. I missed this one.
Please check the attached patch if you still need it.
All comments are followed.
Thanks. :)
On 11/21/2012 06:29 AM, Andrew Morton wrote:
On Fri, 16 Nov 2012 19:58:10 +0800
Wen Congyang wrote:
From: Lai Jiangshan
Now, memory management can handle movable node or nodes which don't have
any normal memory, so we can dynamic configure and add movable node by:
online a ZONE_MOVABLE memory from a previous offline node
offline the last normal memory which result a non-normal-memory-node
movable-node is very important for power-saving,
hardware partitioning and high-available-system(hardware fault management).
...
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -589,11 +589,19 @@ static int online_pages_range(unsigned long start_pfn,
unsigned long nr_pages,
return 0;
}
+#ifdef CONFIG_MOVABLE_NODE
+/* when CONFIG_MOVABLE_NODE, we allow online node don't have normal memory */
The comment is hard to understand. Should it read "When
CONFIG_MOVABLE_NODE, we permit onlining of a node which doesn't have
normal memory"?
+static bool can_online_high_movable(struct zone *zone)
+{
+ return true;
+}
+#else /* #ifdef CONFIG_MOVABLE_NODE */
/* ensure every online node has NORMAL memory */
static bool can_online_high_movable(struct zone *zone)
{
return node_state(zone_to_nid(zone), N_NORMAL_MEMORY);
}
+#endif /* #ifdef CONFIG_MOVABLE_NODE */
/* check which state of node_states will be changed when online memory */
static void node_states_check_changes_online(unsigned long nr_pages,
@@ -1097,6 +1105,13 @@ check_pages_isolated(unsigned long start_pfn, unsigned
long end_pfn)
return offlined;
}
+#ifdef CONFIG_MOVABLE_NODE
+/* when CONFIG_MOVABLE_NODE, we allow online node don't have normal memory */
Ditto, after replacing "online" with offlining".
+static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
+{
+ return true;
+}
+#else /* #ifdef CONFIG_MOVABLE_NODE */
/* ensure the node has NORMAL memory if it is still online */
static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
{
@@ -1120,6 +1135,7 @@ static bool can_offline_normal(struct zone *zone,
unsigned long nr_pages)
*/
return present_pages == 0;
}
+#endif /* #ifdef CONFIG_MOVABLE_NODE */
Please, spend more time over the accuracy and completeness of the
changelog and comments? That will result in better and more
maintainable code. And it results in *much* more effective code
reviewing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
>From f03a9e6ce870b381482bcb1901361d784a9aee4a Mon Sep 17 00:00:00 2001
From: Lai Jiangshan
Date: Wed, 12 Dec 2012 22:49:15 +0900
Subject: [PART4 Patch v2 2/2] memory_hotplug: allow online/offline memory to result movable node
Now, memory management can handle movable node or nodes which don't have
any normal memory, so we can dynamic configure and add movable node by:
online a ZONE_MOVABLE memory from a previous offline node
offline the last normal memory which result a non-normal-memory-node
movable-node is very important for power-saving, hardware partitioning and
high-available-system(hardware fault management).
Cc: Jiang Liu
Cc: KOSAKI Motohiro
Cc: Minchan Kim
Cc: Mel Gorman
Cc: David Rientjes
Cc: Yinghai Lu
Cc: Rusty Russell
Cc: Greg KH
Signed-off-by: Lai Jiangshan
Signed-off-by: Wen Congyang
Signed-off-by: Andrew Morton
Signed-off-by: Tang Chen
Tested-by: Yasuaki Ishimatsu
---
mm/memory_hotplug.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5c19c83..db0e6fb 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -581,11 +581,22 @@ static int online_pages_range(unsigned long start_pfn, unsigned long nr_pages,
return 0;
}
+#ifdef CONFIG_MOVABLE_NODE
+/*
+ * When CONFIG_MOVABLE_NODE, we permit onlining of a node which doesn't have
+ * normal memory.
+ */
+static bool can_online_high_movable(struct zone *zone)
+{
+ return true;
+}
+#else /* #ifdef CONFIG_MOVABLE_NODE */
/* ensure every online node has NORMAL memory */
static bool can_online_high_movable(struct zone *zone)
{
return node_state(zone_to_nid(zone), N_NORMAL_MEMORY);
}
+#endif /* #ifdef CONFIG_MOVABLE_NODE */
/* check which state of node_states will be changed when online memory */
static void node_states_check_changes_online(unsigned long nr_pages,
@@ -1089,6 +1100,16 @@ check_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
return offlined;
}
+#ifdef CONFIG_MOVABLE_NODE
+/*
+ * When CONFIG_MOVABLE_NODE, we permit offlining of a node which doesn't have
+ * normal memory.
+ */
+static bool
[PATCH 2/2] pinctrl: exynos5440: Fix compile error in pinctrl-exynos5440/samsung.c
error: drivers/pinctrl/pinctrl-exynos5440.o: multiple definition of 'pcfgs'
drivers/pinctrl/pinctrl-samsung.o: previous definition here
Signed-off-by: Jonghwan Choi
---
drivers/pinctrl/pinctrl-exynos5440.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-exynos5440.c
b/drivers/pinctrl/pinctrl-exynos5440.c
index b8635f6..8a863a3 100644
--- a/drivers/pinctrl/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/pinctrl-exynos5440.c
@@ -117,7 +117,7 @@ struct exynos5440_pinctrl_priv_data {
};
/* list of all possible config options supported */
-struct pin_config {
+static const struct pin_config {
char*prop_cfg;
unsigned intcfg_type;
} pcfgs[] = {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit
On Sun, Dec 16, 2012 at 4:42 PM, Yinghai Lu wrote: > On Sun, Dec 16, 2012 at 3:59 PM, Yu, Fenghua wrote: >> >>> it has to be rebased after #PF handler version. otherwise it can not >>> handle for framdisk >>> that is loaded after 1G. >>> >>> Fenghua, >>> >>> can you post your boot log with 64bit with your patch? >>> >>> Yinghai >> >> Attached is dmesg with the patches. >> > > yes, your laptop only have 1G ram, and > > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable > [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0x3e6a] usable > [0.00] BIOS-e820: [mem 0x3e6b-0x3e6ccfff] ACPI > data > [0.00] BIOS-e820: [mem 0x3e6cd000-0x3e6f] ACPI NVS > [0.00] BIOS-e820: [mem 0x3e70-0x3eff] reserved > [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved > [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved > [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > [0.00] BIOS-e820: [mem 0xff00-0x] reserved > > ramdisk is at > RAMDISK: [mem 0x27608000-0x2fafbfff] > > and current kernel default set 1G to kernel mapping. so it happens to > work with your patchset. > > please find one sytem with 4G or more to test it. > > and you may need to rebase your patches on top of my for-x86-boot > branch with working > #PF handler set page table patch. > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-x86-boot also you did not consider initrd relocating please check attached fix, and see if you can fold in into you next posting. Thanks Yinghai fix_microcode_v4.patch Description: Binary data
[PATCH 1/2] pinctrl: samsung: Fix compile error in pinctrl-exynos5440/samsung.c
error: drivers/pinctrl/pinctrl-exynos5440.o: multiple definition of 'pcfgs'
drivers/pinctrl/pinctrl-samsung.o: previous definition here
Signed-off-by: Jonghwan Choi
---
drivers/pinctrl/pinctrl-samsung.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
index 8f31b65..fc98b38 100644
--- a/drivers/pinctrl/pinctrl-samsung.c
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -37,7 +37,7 @@
#define FSUFFIX_LENsizeof(FUNCTION_SUFFIX)
/* list of all possible config options supported */
-struct pin_config {
+static const struct pin_config {
char*prop_cfg;
unsigned intcfg_type;
} pcfgs[] = {
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the btrfs tree
On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote: > Hi Chris, > > After merging the btrfs tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > fs/btrfs/ioctl.c: In function 'btrfs_ioctl': > fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer > constant Many thanks Stephen for helping debug this. It turned out to be the size of the ioctl arg was just too big. Stefan, I lowered this by using BTRFS_DEVICE_PATH_NAME_MAX instead, and I also put the char arrays after the u64s. It works here with the progs patch you sent (and matching struct changes), including cancel and the btrfs replace -r mode. I've pushed the result out to my next branch and my for-linus branch, please take a look and make sure I didn't miss anything. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] Add help info for CONFIG_MOVABLE_NODE and disable is by default
The first patch adds help info for CONFIG_MOVABLE_NODE option. The second patch disable this option by default. change log v1 -> v2: Fix spelling comments from Ingo. Tang Chen (2): memory-hotplug: Add help info for CONFIG_MOVABLE_NODE option memory-hotplug: Disable CONFIG_MOVABLE_NODE option by default. mm/Kconfig | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) -- 1.7.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] memory-hotplug: Add help info for CONFIG_MOVABLE_NODE option
This patch adds help info for CONFIG_MOVABLE_NODE option. This option allows user to online all memory of a node as movable memory. So that the whole node can be hotpluged. Users who don't use hotplug feature are also fine with this option on since they won't online memory as movable. Signed-off-by: Tang Chen Reviewed-by: Yasuaki Ishimatsu Acked-by: Ingo Molnar --- mm/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/mm/Kconfig b/mm/Kconfig index 71259e0..491 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -150,6 +150,16 @@ config MOVABLE_NODE depends on X86_64 depends on NUMA depends on BROKEN + help + Allow a node to have only movable memory. Pages used by the kernel, + such as direct mapping pages can not be migrated. So the corresponding + memory device can not be hotplugged. This option allows users to online + all the memory of a node as movable memory so that the whole node can + be hot-unplugged. Users who don't use the hotplug feature are fine + with this option on since they don't online memory as movable. + + Say Y here if you want to hotplug a whole node. + Say N here if you want kernel to use memory on all nodes evenly. # eventually, we can have this option just 'select SPARSEMEM' config MEMORY_HOTPLUG -- 1.7.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] memory-hotplug: Disable CONFIG_MOVABLE_NODE option by default.
This patch set CONFIG_MOVABLE_NODE to "default n" instead of "depends on BROKEN". Signed-off-by: Tang Chen Reviewed-by: Yasuaki Ishimatsu --- mm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/Kconfig b/mm/Kconfig index 491..bbd6bfa 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -149,7 +149,7 @@ config MOVABLE_NODE depends on NO_BOOTMEM depends on X86_64 depends on NUMA - depends on BROKEN + default n help Allow a node to have only movable memory. Pages used by the kernel, such as direct mapping pages can not be migrated. So the corresponding -- 1.7.10.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH for 3.2.34] memcg: do not trigger OOM from add_to_page_cache_locked
>I would try to limit changes to minimum. So the original kernel you were >using + the first patch to prevent OOM from the write path + 2 debugging >patches. It didn't take off the whole system this time (but i was prepared to record a video of console ;) ), here it is: http://www.watchdog.sk/lkml/oom_mysqld4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] regulator: new driver for LP8755
This patch is for new lp8755 regulator dirver and
several unsed variables were deleted and then test was done.
LP8755 :
The LP8755 is a high performance power management unit.It contains
six step-down DC-DC converters which can can be filexibly bundled
together in multiphase converters as required by application.
www.ti.com
Signed-off-by: Daniel Jeong
---
drivers/regulator/Kconfig|9 +
drivers/regulator/Makefile |1 +
drivers/regulator/lp8755.c | 580 ++
include/linux/platform_data/lp8755.h | 71
4 files changed, 661 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/lp8755.c
create mode 100644 include/linux/platform_data/lp8755.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 67d47b59..dc83401 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -257,6 +257,15 @@ config REGULATOR_LP872X
help
This driver supports LP8720/LP8725 PMIC
+config REGULATOR_LP8755
+ tristate "TI LP8755 High Performance PMU driver"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ This driver supports LP8755 High Performance PMU driver. This
+ chip contains six step-down DC/DC converters which can support
+ 9 mode multiphase configuration.
+
config REGULATOR_LP8788
bool "TI LP8788 Power Regulators"
depends on MFD_LP8788
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index e431eed..bf346b7 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_REGULATOR_LP3972) += lp3972.o
obj-$(CONFIG_REGULATOR_LP872X) += lp872x.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-buck.o
obj-$(CONFIG_REGULATOR_LP8788) += lp8788-ldo.o
+obj-$(CONFIG_REGULATOR_LP8755) += lp8755.o
obj-$(CONFIG_REGULATOR_MAX1586) += max1586.o
obj-$(CONFIG_REGULATOR_MAX8649)+= max8649.o
obj-$(CONFIG_REGULATOR_MAX8660) += max8660.o
diff --git a/drivers/regulator/lp8755.c b/drivers/regulator/lp8755.c
new file mode 100644
index 000..dbc4d12
--- /dev/null
+++ b/drivers/regulator/lp8755.c
@@ -0,0 +1,580 @@
+/*
+ * LP8755 High Performance Power Management Unit : System Interface Driver
+ * (based on rev. 0.26)
+ * Copyright 2012 Texas Instruments
+ *
+ * Author: Daniel(Geon Si) Jeong
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define LP8755_REG_BUCK0 0x00
+#define LP8755_REG_BUCK1 0x03
+#define LP8755_REG_BUCK2 0x04
+#define LP8755_REG_BUCK3 0x01
+#define LP8755_REG_BUCK4 0x05
+#define LP8755_REG_BUCK5 0x02
+#define LP8755_REG_MAX 0xFF
+
+#define LP8755_BUCK_EN_M BIT(7)
+#define LP8755_BUCK_LINEAR_OUT_MAX 0x76
+#define LP8755_BUCK_VOUT_M 0x7F
+
+enum bucks {
+ BUCK0 = 0,
+ BUCK1,
+ BUCK2,
+ BUCK3,
+ BUCK4,
+ BUCK5,
+};
+
+struct lp8755_mphase {
+ int nreg;
+ int buck_num[LP8755_BUCK_MAX];
+};
+
+struct lp8755_chip {
+ struct device *dev;
+ struct regmap *regmap;
+ struct lp8755_platform_data *pdata;
+
+ int irq;
+ unsigned int irqmask;
+
+ int mphase;
+ struct regulator_dev *rdev[LP8755_BUCK_MAX];
+};
+
+/**
+ *lp8755_read : read a single register value from lp8755.
+ *@pchip : device to read from
+ *@reg : register to read from
+ *@val : pointer to store read value
+ */
+static int lp8755_read(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(pchip->regmap, reg, val);
+}
+
+/**
+ *lp8755_write : write a single register value to lp8755.
+ *@pchip : device to write to
+ *@reg : register to write to
+ *@val : value to be written
+ */
+static int lp8755_write(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int val)
+{
+ return regmap_write(pchip->regmap, reg, val);
+}
+
+/**
+ *lp8755_update_bits : set the values of bit fields in lp8755 register.
+ *@pchip : device to read from
+ *@reg : register to update
+ *@mask : bitmask to be changed
+ *@val : value for bitmask
+ */
+static int lp8755_update_bits(struct lp8755_chip *pchip, unsigned int reg,
+ unsigned int mask, unsigned int val)
+{
+ return regmap_update_bits(pchip->regmap, reg, mask, val);
+}
+
+static int lp8755_buck_enable_time(struct regulator_dev *rdev)
+{
+ int ret;
+ unsigned int regval;
+ enum lp8755_bucks id = rdev_get_id(rdev);
+ struct lp8755_chip *pchip = rdev_get_drvdata(rdev);
+
+ ret = lp8755_read(pchip, 0x12 + id, );
+ if (ret < 0) {
+ dev_err(pchip->dev,
Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
Hi David, On Mon, Dec 17, 2012 at 12:17:21AM +, David Woodhouse wrote: > On Mon, 2010-11-22 at 08:52 +0100, Eric Dumazet wrote: > > Le dimanche 21 novembre 2010 à 18:40 -0800, Kevin Cernekee a écrit : > > > [v3: > > > Only activate the new forced_dport logic if the IP matches, but the > > > port does not. ] > > > > > > Most SIP devices use a source port of 5060/udp on SIP requests, so the > > > response automatically comes back to port 5060: > > > > > > phone_ip:5060 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > > > The newer Cisco IP phones, however, use a randomly chosen high source > > > port for the SIP request but expect the response on port 5060: > > > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:5060 100 Trying > > > > > > Standard Linux NAT, with or without nf_nat_sip, will send the reply back > > > to port 49173, not 5060: > > > > > > phone_ip:49173 -> proxy_ip:5060 REGISTER > > > proxy_ip:5060 -> phone_ip:49173 100 Trying > > > > > > But the phone is not listening on 49173, so it will never see the reply. > > > > > > This patch modifies nf_*_sip to work around this quirk by extracting > > > the SIP response port from the Via: header, iff the source IP in the > > > packet header matches the source IP in the SIP request. > > > > > > Signed-off-by: Kevin Cernekee > > > --- > > > > Thanks for doing this work Keven ! > > > > Acked-by: Eric Dumazet > > What happened to this? OpenWRT is still carrying it, and it broke in > 3.7. Here's a completely untested update... I requested Kevin to resend a new version based on the current kernel tree while spinning on old pending patches since I have no access to that hardware, but no luck. So I'll review this and, since OpenWRT is carrying, I guess we can get this into net-next merge window. Thanks for the reminder. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit
On Sun, Dec 16, 2012 at 3:59 PM, Yu, Fenghua wrote: > >> it has to be rebased after #PF handler version. otherwise it can not >> handle for framdisk >> that is loaded after 1G. >> >> Fenghua, >> >> can you post your boot log with 64bit with your patch? >> >> Yinghai > > Attached is dmesg with the patches. > yes, your laptop only have 1G ram, and [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3e6a] usable [0.00] BIOS-e820: [mem 0x3e6b-0x3e6ccfff] ACPI data [0.00] BIOS-e820: [mem 0x3e6cd000-0x3e6f] ACPI NVS [0.00] BIOS-e820: [mem 0x3e70-0x3eff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved [0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved ramdisk is at RAMDISK: [mem 0x27608000-0x2fafbfff] and current kernel default set 1G to kernel mapping. so it happens to work with your patchset. please find one sytem with 4G or more to test it. and you may need to rebase your patches on top of my for-x86-boot branch with working #PF handler set page table patch. git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] EXTCON: Get and set cable properties
On 12/15/2012 09:16 AM, Tc, Jenny wrote: > >>> I replied on the thread and pointed out issues that I see with this >>> solution. IMHO It's not fair to register a cable with >>> power_supply/regulator/charger manager just to expose the cable >> properties. >> Don't we do that with already in allmost all drivers?Like if I have a >> keyboard >> driver and then I register with input framework and if the keyboard driver >> needs clk services then I register with clk framework as well and same with >> other services needed by keyboard driver.I think it makes sense for a cable >> to register with different framework if it supports that functionality as >> those >> services also would know that we have a cable with so and so property. > > IMHO it's not a good choice to register a cable itself with any of the three > subsystem > (power_supply/regulator/charger manager) > > For example it cannot register with power_supply subsystem since it's not a > power_supply. It's just source for a power_supply.We register either > charger/battery with > power supply. I couldn't find a way to register the cable with power supply > subsystem. > > In previous discussion Anton also agreed to this. > > Anton, > Could you please confirm? > > I think the same case with regulator framework also. A cable doesn’t belong > to a regulator framework. > A cable doesn’t expose any control attribute (current control/voltage > control). It just have properties (eg current) > controlled by external agents (Host machine/wall charger) > > And charger manager is a consumer and not a provider. It cannot decide the > charger cable capabilities. No, charger-manager include information for battery/charger/charger cable dependency on target H/W. Each target has different h/w constraint for charging, so charger-manager can determine whether specific charger cable is used on target or not. > > As I said, extcon provider driver didn't provide directly charging current(int mA) and some state(unsigned long state) because the extcon provider driver(Micro USB interface controller device or other device related to external connector) haven't mechanism which detect dynamically charging current immediately. If you wish to provide charging current data to extcon consumer driver or framework, you should use regulator/power_supply framework or other method in extcon provider >> driver. > > This information need not to come from the extcon provider. It can come from > any driver > Who knows the state of a cable. It may be a platform driver or may be a > driver belongs to any > of the three subsystem we discussed above > (power_supply/regulator/charger_manager). > Just by having an API like this (extcon_cable_set_data), it's not mandatory > to register the cable > with any of the subsystem. > Also if you want to define 'struct extcon_chrgr_cable_props', you should certainly show how detect dynamically charging current or state. > > For USB cables, it's determined by USB enumeration. For USB 3.0 it would be > 900mA and > USB 2.0 it's 500mA. Also in un configured state this would be 150 and 100mA > respectively I think only USB enumeration determine standard charging current according to version of USB. But, Extcon subsystem always need detection mechanism. (e.g, Jack/Microphone detection device of Wolfson sound codec and MUIC(Micro USB Interface Controller) device of MAXIM) You didn't show any detection mechanism which detect changed state of host system. What can some device for detecting of following host state except of CONNECT/DISCONNECT state? I don't know. Please let me know it. - SUSPEND(Host suspend for SDP cable), - RESUME(Host wakeup) - UPDATE (to increase the charge current after USB enumaeration). - CONNECT - DISCOONECT -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
On Mon, 2010-11-22 at 08:52 +0100, Eric Dumazet wrote:
> Le dimanche 21 novembre 2010 à 18:40 -0800, Kevin Cernekee a écrit :
> > [v3:
> > Only activate the new forced_dport logic if the IP matches, but the
> > port does not. ]
> >
> > Most SIP devices use a source port of 5060/udp on SIP requests, so the
> > response automatically comes back to port 5060:
> >
> > phone_ip:5060 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:5060 100 Trying
> >
> > The newer Cisco IP phones, however, use a randomly chosen high source
> > port for the SIP request but expect the response on port 5060:
> >
> > phone_ip:49173 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:5060 100 Trying
> >
> > Standard Linux NAT, with or without nf_nat_sip, will send the reply back
> > to port 49173, not 5060:
> >
> > phone_ip:49173 -> proxy_ip:5060 REGISTER
> > proxy_ip:5060 -> phone_ip:49173 100 Trying
> >
> > But the phone is not listening on 49173, so it will never see the reply.
> >
> > This patch modifies nf_*_sip to work around this quirk by extracting
> > the SIP response port from the Via: header, iff the source IP in the
> > packet header matches the source IP in the SIP request.
> >
> > Signed-off-by: Kevin Cernekee
> > ---
>
> Thanks for doing this work Keven !
>
> Acked-by: Eric Dumazet
What happened to this? OpenWRT is still carrying it, and it broke in
3.7. Here's a completely untested update...
+ if (!skb_make_writable(skb, skb->len))
+ return NF_DROP;
+
-+ uh = (struct udphdr *)(skb->data + ip_hdrlen(skb));
++ uh = (void *)skb->data + protoff;
+ uh->dest = ct_sip_info->forced_dport;
+
-+ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, 0, 0, NULL, 0))
++ if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff, 0, 0, NU
+ return NF_DROP;
+ }
+
return NF_ACCEPT;
}
diff --git a/include/linux/netfilter/nf_conntrack_sip.h
b/include/linux/netfilter/nf_conntrack_sip.h
index 387bdd0..ba7f571 100644
--- a/include/linux/netfilter/nf_conntrack_sip.h
+++ b/include/linux/netfilter/nf_conntrack_sip.h
@@ -4,12 +4,15 @@
#include
+#include
+
#define SIP_PORT 5060
#define SIP_TIMEOUT3600
struct nf_ct_sip_master {
unsigned intregister_cseq;
unsigned intinvite_cseq;
+ __be16 forced_dport;
};
enum sip_expectation_classes {
diff --git a/net/netfilter/nf_conntrack_sip.c b/net/netfilter/nf_conntrack_sip.c
index df8f4f2..72a67bb 100644
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1440,8 +1440,25 @@ static int process_sip_request(struct sk_buff *skb,
unsigned int protoff,
{
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, );
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
+ enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
unsigned int matchoff, matchlen;
unsigned int cseq, i;
+ union nf_inet_addr addr;
+ __be16 port;
+
+ /* Many Cisco IP phones use a high source port for SIP requests, but
+* listen for the response on port 5060. If we are the local
+* router for one of these phones, save the port number from the
+* Via: header so that nf_nat_sip can redirect the responses to
+* the correct port.
+*/
+ if (ct_sip_parse_header_uri(ct, *dptr, NULL, *datalen,
+ SIP_HDR_VIA_UDP, NULL, ,
+ , , ) > 0 &&
+ port != ct->tuplehash[dir].tuple.src.u.udp.port &&
+ nf_inet_addr_cmp(, >tuplehash[dir].tuple.src.u3))
+ ct_sip_info->forced_dport = port;
for (i = 0; i < ARRAY_SIZE(sip_handlers); i++) {
const struct sip_handler *handler;
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index 16303c7..552e270 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -95,6 +95,7 @@ static int map_addr(struct sk_buff *skb, unsigned int protoff,
enum ip_conntrack_info ctinfo;
struct nf_conn *ct = nf_ct_get(skb, );
enum ip_conntrack_dir dir = CTINFO2DIR(ctinfo);
+ struct nf_ct_sip_master *ct_sip_info = nfct_help_data(ct);
char buffer[INET6_ADDRSTRLEN + sizeof("[]:n")];
unsigned int buflen;
union nf_inet_addr newaddr;
@@ -107,7 +108,8 @@ static int map_addr(struct sk_buff *skb, unsigned int
protoff,
} else if (nf_inet_addr_cmp(>tuplehash[dir].tuple.dst.u3, addr) &&
ct->tuplehash[dir].tuple.dst.u.udp.port == port) {
newaddr = ct->tuplehash[!dir].tuple.src.u3;
- newport = ct->tuplehash[!dir].tuple.src.u.udp.port;
+ newport = ct_sip_info->forced_dport ? ct_sip_info->forced_dport
:
+ ct->tuplehash[!dir].tuple.src.u.udp.port;
} else
Re: linux-next: build failure after merge of the btrfs tree
On Sun, Dec 16, 2012 at 04:00:22PM -0700, Stephen Rothwell wrote:
> Hi Chris,
>
> After merging the btrfs tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/btrfs/ioctl.c: In function 'btrfs_ioctl':
> fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer
> constant
Thanks Stephen. In my sources, this line is:
case BTRFS_IOC_DEV_REPLACE:
And the define is:
#define BTRFS_IOC_DEV_REPLACE _IOWR(BTRFS_IOCTL_MAGIC, 53, \
struct btrfs_ioctl_dev_replace_args)
Is there a way to see what ppc64 is doing with this macro?
>
> Caused by commit 0aa7cbc7585a ("Btrfs: add support for device replace
> ioctls").
>
> I have used the btrfs tree from next-20121214 for today (which was empty).
>
> I have to say that these btrfs commits have come to linux-next very late
> in the game (i.e. some of them have author dates back in September and
> October and yet they only appeared in linux-next today).
This is true, we've had these in testing for some time. Especially when
new interfaces come in, we tend to delay them.
> Also, the
> committer of this commits is Josef Bacik but there
> is not Signed-off-by him. There are other commits that are committed by
> you, Chris, that also do not have a Signed-off-by you.
Josef and I have sob on all of our commits (at least all the ones not in
3.7, I didn't go back farther). In this case the Author was Stefan and
it ended up rebased in either Josef's or my tree. We usually try to
preserve merges on rebase, but this time was a bigger set of changes
than usual and it didn't work out.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] Security subsystem updates for 3.8
On Sat, Dec 15, 2012 at 12:28 AM, James Morris wrote: > A quiet cycle for the security subsystem with just a few maintenance > updates. Ok, pulled. There were a few trivial conflicts (mostly due to some of the key allocation patches having already been merged, and some of the kuid/kgid changes due to the userns changes). I'd like you to double-check the end result, but it *looks* fine. Adding both EricB and DavidH to the participants since the conflicts were generally due to intetractions with their patches. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 2012.12.16 at 14:07 -0800, Linus Torvalds wrote: > On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds > wrote: > > > > So I'll test it and see, and hope for the best, > > No such luck. Applying your patch and the reverting the revert of the > EFI date thing results in the same oops in find_vma() from udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. Hm, I just double checked my logs and it looks like I've booted the wrong kernel. The new patch fails for me, too. Sorry for the confusion. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit
On Sun, Dec 16, 2012 at 1:43 PM, H. Peter Anvin wrote:
> On 12/16/2012 09:59 AM, Yinghai Lu wrote:
>>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>>> index 037df57..a512f56 100644
>>> --- a/arch/x86/kernel/head64.c
>>> +++ b/arch/x86/kernel/head64.c
>>> @@ -25,6 +25,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> static void __init zap_identity_mappings(void)
>>> {
>>> @@ -73,6 +74,11 @@ void __init x86_64_start_kernel(char * real_mode_data)
>>> /* clear bss before set_intr_gate with early_idt_handler */
>>> clear_bss();
>>>
>>> + /*
>>> +* Load microcode early on BSP.
>>> +*/
>>> + load_ucode_bsp(real_mode_data);
>>> +
>>> /* Make NULL pointers segfault */
>>> zap_identity_mappings();
>>>
>>
>> So this patchset is after #PF handler set early page table version?
>>
>> then load_ucode_bsp() should be after
>>
>>load_idt((const struct desc_ptr *)_descr);
>>
>
> This patchset isn't before the #PF handler version (you can tell because
> it has zap_identity_mappings()), but it does make sense to load the IDT
> first.
it has to be rebased after #PF handler version. otherwise it can not
handle for framdisk
that is loaded after 1G.
Fenghua,
can you post your boot log with 64bit with your patch?
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Automatic NUMA Balancing V11
On Wed, Dec 12, 2012 at 2:03 AM, Mel Gorman wrote: > This is a pull request for "Automatic NUMA Balancing V11". The list Ok, guys, I've pulled this and pushed out. There were some conflicts with both the VM changes and with the scheduler tree, but they were pretty small and looked simple, so I fixed them up and hope they all work. Has anybody tested the impact on single-node systems? If distros enable this by default (and it does have 'default y', which is a big no-no for new features - I undid that part) then there will be tons of people running this without actually having multiple sockets. Does it gracefully avoid pointless overheads for this case? Anyway, hopefully we'll have a more real numa balancing for 3.9, and this is still considered a reasonable base for that work. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the btrfs tree
Hi Chris,
After merging the btrfs tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/btrfs/ioctl.c: In function 'btrfs_ioctl':
fs/btrfs/ioctl.c:3940:7: error: case label does not reduce to an integer
constant
Caused by commit 0aa7cbc7585a ("Btrfs: add support for device replace ioctls").
I have used the btrfs tree from next-20121214 for today (which was empty).
I have to say that these btrfs commits have come to linux-next very late
in the game (i.e. some of them have author dates back in September and
October and yet they only appeared in linux-next today). Also, the
committer of this commits is Josef Bacik but there
is not Signed-off-by him. There are other commits that are committed by
you, Chris, that also do not have a Signed-off-by you.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpUD3Cis9RJW.pgp
Description: PGP signature
Re: [GIT PULL] x86/uapi for 3.8
On Sun, Dec 16, 2012 at 2:40 PM, Matt Fleming wrote: > > Linus have you got a stacktrace for the oops (and maybe even a dmesg)? I > suspect it won't tell us much, but any/all info we can gather will help. Sadly, it starts scrolling away pretty quickly, and it really wasn't very useful. None of the traces contained any of the new code. The backtrace was something like "find_vma()" called by "do_munmap()". I do have a phone picture of an earlier oops, which was similar. In that case, the oops happened in "unmap_single_vma()", with the call trace being unmap_vmas exit_mmap mmput do_exit do_group_exit get_signal_to_deliver do_signal do_notify_resume retint_signal which looks rather similar: it's some kind of nasty vma list corruption. The main difference being that the exit of the process happened as a result of a signal rather than just a plain exit() system call. Which is probably in turn the result of some corruption of user-space data structures. In some other cases, I've got quickly scrolling stuff that I couldn't even guess at, or just a hung system at early boot. > At this point, I'm wondering if insert_identity_mapping() is trashing > valid mappings. It does feel like *major* data corruption. As in "not just a bitflip or two", but "megabytes of data is wrong". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] tx/rx LED trigger support
Hello Marc, On Sun, Dec 16, 2012 at 11:37:59PM +0100, Marc Kleine-Budde wrote: > Thanks for your work. Can you move patches 8+9 to the beginning, before > touching the device drivers. I'll apply on the Thursday, as I don't have > proper internet now. Ok, it makes sense. In that case I'll wait a couple of days before re-sending the reordered series, just in case someone else wants to comment. Thanks! Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sun, 2012-12-16 at 14:07 -0800, Linus Torvalds wrote: > On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds > wrote: > > > > So I'll test it and see, and hope for the best, > > No such luck. Applying your patch and the reverting the revert of the > EFI date thing results in the same oops in find_vma() from udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. Linus have you got a stacktrace for the oops (and maybe even a dmesg)? I suspect it won't tell us much, but any/all info we can gather will help. At this point, I'm wondering if insert_identity_mapping() is trashing valid mappings. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/9] tx/rx LED trigger support
On 12/16/2012 12:08 PM, Fabio Baltieri wrote: > Hi all, > > this is a resend of the patch series on tx/rx LEDs trigger. The patch > set was put on hold after the latest discussions on Kurt's rename patch > due to a missing feature in the LED subsystem, which has been just > merged in: > > a8df7b1 leds: add led_trigger_rename function > > So, as months passed since the latest developments, I'm reposting the > whole set, rebased on current mainline. The first patches are the same > that were merged in can-next/led-trigger, but there was some (trivial) > conflict in the rebase. > > As for the test, I've tried the patch on the current mainline kernel > with my custom usb-can interface. For the drivers, I don't have any > SoC-enabled board anymore, so they have only been compile tested. Thanks for your work. Can you move patches 8+9 to the beginning, before touching the device drivers. I'll apply on the Thursday, as I don't have proper internet now. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: problem: [PATCH] iptable_REJECT doesn't constructs the tcp reset packet cleanly
On Tue, Dec 11, 2012 at 01:58:02AM +0100, Pablo Neira Ayuso wrote:
[...]
> On Mon, Dec 10, 2012 at 12:48:49PM -0800, Mukund Jampala wrote:
> > problem description:
> > The problem occurs when iptables constructs the tcp reset packet.
> > It doesn't initialize the pointer to the tcp header within the skb.
> > When the skb is passed to the ixgbe driver for transmit, the ixgbe
> > driver attempts to access the tcp header and crashes.
> > Currently, other drivers (such as our 1G e1000e or igb drivers) don't
> > access the tcp header on transmit unless the TSO option is turned on.
[...]
> > Solution: set the skb->trasport_header to a valid data offset in ipt
> > reject module
> >
> > diff -up net/ipv4/netfilter/ipt_REJECT.c{.orig,}
> > --- net/ipv4/netfilter/ipt_REJECT.c.orig2012-12-10 12:08:37.0
> > -0800
> > +++ net/ipv4/netfilter/ipt_REJECT.c 2012-12-10 12:10:08.0 -0800
> > @@ -79,6 +79,8 @@ static void send_reset(struct sk_buff *o
> > niph->saddr = oiph->daddr;
> > niph->daddr = oiph->saddr;
> >
> > +
> > + skb_reset_transport_header(nskb);
> > tcph = (struct tcphdr *)skb_put(nskb, sizeof(struct tcphdr));
> > memset(tcph, 0, sizeof(*tcph));
> > tcph->source= oth->dest;
> >
> > Please let me know if you have any concerns with the patch.
>
> This is a good and extensive diagnosing, thanks a lot.
>
> Regarding your patch format, please, use git format-patch for your
> upcoming contributions and add the Signed-off-by tag to your patches.
> It makes
>
> But for this time, I'll do the formatting myself and will take this
> into the nf tree.
I have also made the same change for ip6t_REJECT.
Applied, thanks Mukund.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
On Tue, 11 Dec 2012 10:40:01 +0100 Lars-Peter Clausen wrote: > > Yes, move the header or merge into existing one as makes sense. > > I'm not pulling this driver into the IIO tree (unless for some > > reason Alessandro wants me to and I can't think why he would...). > > > > Alessandro has been pretty quiet for quite some time now. Luckily Andrew > Morton usually picks up the stuff for orphaned subsystems. So put him on Cc > for v4. Still reading e-mails ;) Andrew monitors the rtc mailing list and picks up the patches that do not need to go in any arch's main tree, which is the suggested way as, with modern chipsets, the RTCs shares hw with many other drivers. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI: Simplify namespace scanning for devices
On Sunday, December 16, 2012 09:36:49 AM Yinghai Lu wrote: > On Sun, Dec 16, 2012 at 5:47 AM, Rafael J. Wysocki wrote: > > Hi All, > > > > This series is on top of the one I sent on Thursday: > > > > https://lkml.org/lkml/2012/12/13/632 > > > > It goes one step farther and makes some simplifications that become possible > > after applying that patchset. > > > > [1/6] Fold acpi_pci_root_start() into acpi_pci_root_add() > > [2/6] Remove acpi_start_single_object() and acpi_bus_start() > > [3/6] Remove the arguments of acpi_bus_add() that are not used > > [4/6] Drop the second argument of acpi_bus_scan() > > [5/6] Replace ACPI device add_type field with a match_driver flag > > [6/6] Make acpi_bus_scan() and acpi_bus_add() take only one argument > > > > It survives booting on Toshiba Portege R500 without any visible issues. > > Do you have git branch that i could test? There you go: git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-scan-temp > I'd like to rebase for-pci-root-bus-hotplug patches, so what should be base? I'll need to talk about that with Bjorn. Hopefully he'll be reachable tomorrow. > It would be hard for me to base on your acpi tree and Bjorn's pci tree. We'll work out something. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/16/2012 02:07 PM, Linus Torvalds wrote: > On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds > wrote: >> >> So I'll test it and see, and hope for the best, > > No such luck. Applying your patch and the reverting the revert of the > EFI date thing results in the same oops in find_vma() from udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. > No, we need to get to the bottom with the problem. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] Please pull powerpc.git next branch
On Sat, 2012-12-15 at 07:44 +1100, Benjamin Herrenschmidt wrote: > Finally managed to get my head away from some other distractions > to put this pull request together, sorry for the lateness :-) > > The main highlight is probably some base POWER8 support. There's > more to come such as transactional memory support but that will > wait for the next one. To clear up some misunderstanding, here I meant next merge window. > Overall it's pretty quiet, or rather I've been pretty poor at > picking things up from patchwork and reviewing them this time > around and Kumar no better on the FSL side it seems... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI: Simplify namespace scanning for devices
Hi, On Sunday, December 16, 2012 11:59:58 PM Jiang Liu wrote: > Hi Rafael, > Great idea to get rid of the .start() staff, it could also > simplify our hotplug framework too. Well, this has been a Yinghai's idea, but thanks anyway. :-) I see some more room for improvements like this, for example in the acpi_pci_bind()/acpi_pci_unbind() area. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / PCI: Set root bridge ACPI handle in advance
From: Rafael J. Wysocki
The ACPI handles of PCI root bridges need to be known to
acpi_bind_one(), so that it can create the appropriate
"firmware_node" and "physical_node" files for them, but currently
the way it gets to know those handles is not exactly straightforward
(to put it lightly).
This is how it works, roughly:
1. acpi_bus_scan() finds the handle of a PCI root bridge,
creates a struct acpi_device object for it and passes that
object to acpi_pci_root_add().
2. acpi_pci_root_add() creates a struct acpi_pci_root object,
populates its "device" field with its argument's address
(device->handle is the ACPI handle found in step 1).
3. The struct acpi_pci_root object created in step 2 is passed
to pci_acpi_scan_root() and used to get resources that are
passed to pci_create_root_bus().
4. pci_create_root_bus() creates a struct pci_host_bridge object
and passes its "dev" member to device_register().
5. platform_notify(), which for systems with ACPI is set to
acpi_platform_notify(), is called.
So far, so good. Now it starts to be "interesting".
6. acpi_find_bridge_device() is used to find the ACPI handle of
the given device (which is the PCI root bridge) and executes
acpi_pci_find_root_bridge(), among other things, for the
given device object.
7. acpi_pci_find_root_bridge() uses the name (sic!) of the given
device object to extract the segment and bus numbers of the PCI
root bridge and passes them to acpi_get_pci_rootbridge_handle().
8. acpi_get_pci_rootbridge_handle() browses the list of ACPI PCI
root bridges and finds the one that matches the given segment
and bus numbers. Its handle is then used to initialize the
ACPI handle of the PCI root bridge's device object by
acpi_bind_one(). However, this is *exactly* the ACPI handle we
started with in step 1.
Needless to say, this is quite embarassing, but it may be avoided
thanks to commit f3fd0c8 (ACPI: Allow ACPI handles of devices to be
initialized in advance), which makes it possible to initialize the
ACPI handle of a device before passing it to device_register().
Namely, if pci_acpi_scan_root() could easily pass the root bridge's
ACPI handle to pci_create_root_bus(), the latter could set the ACPI
handle in its struct pci_host_bridge object's "dev" member before
passing it to device_register() and steps 6-8 above wouldn't be
necessary any more.
To make that happen I decided to repurpose the 4th argument of
pci_create_root_bus(), because that allowed me to avoid defining
additional callbacks or similar things and didn't seem to impact
architectures without ACPI substantially.
Only x86 and ia64 are affected directly, there should be no
functional changes resulting from this on other architectures.
Signed-off-by: Rafael J. Wysocki
---
Should apply to the current Linus' tree, boots correctly on x86(-64).
Thanks,
Rafael
---
arch/ia64/pci/pci.c |5 -
arch/powerpc/kernel/pci-common.c |3 ++-
arch/sparc/kernel/pci.c |3 ++-
arch/x86/pci/acpi.c |5 -
drivers/acpi/pci_root.c | 18 --
drivers/pci/pci-acpi.c | 19 ---
drivers/pci/probe.c | 16 +++-
include/acpi/acpi_bus.h |1 -
include/linux/pci.h |9 -
9 files changed, 31 insertions(+), 48 deletions(-)
Index: linux/arch/x86/pci/acpi.c
===
--- linux.orig/arch/x86/pci/acpi.c
+++ linux/arch/x86/pci/acpi.c
@@ -450,6 +450,7 @@ struct pci_bus * __devinit pci_acpi_scan
LIST_HEAD(resources);
struct pci_bus *bus = NULL;
struct pci_sysdata *sd;
+ struct pci_root_sys_info si;
int node;
#ifdef CONFIG_ACPI_NUMA
int pxm;
@@ -486,6 +487,8 @@ struct pci_bus * __devinit pci_acpi_scan
sd = >sd;
sd->domain = domain;
sd->node = node;
+ si.acpi_node.handle = device->handle;
+ si.sysdata = sd;
/*
* Maybe the desired pci bus has been already scanned. In such case
* it is unnecessary to scan the pci bus with the given domain,busnum.
@@ -517,7 +520,7 @@ struct pci_bus * __devinit pci_acpi_scan
if (!setup_mcfg_map(info, domain, (u8)root->secondary.start,
(u8)root->secondary.end, root->mcfg_addr))
bus = pci_create_root_bus(NULL, busnum, _root_ops,
- sd, );
+ , );
if (bus) {
pci_scan_child_bus(bus);
Index: linux/drivers/pci/probe.c
===
--- linux.orig/drivers/pci/probe.c
+++ linux/drivers/pci/probe.c
@@ -1630,7 +1630,9 @@ unsigned int __devinit pci_scan_child_bu
}
struct pci_bus
Re: [GIT PULL] x86/uapi for 3.8
On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds wrote: > > So I'll test it and see, and hope for the best, No such luck. Applying your patch and the reverting the revert of the EFI date thing results in the same oops in find_vma() from udev that I had before. So the patch is still scrogged, and it is *not* ready to even be put in some "next merge window" pile. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 08/10] x86/head64.c: Early update ucode in 64-bit
On 12/16/2012 09:59 AM, Yinghai Lu wrote:
>> diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
>> index 037df57..a512f56 100644
>> --- a/arch/x86/kernel/head64.c
>> +++ b/arch/x86/kernel/head64.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> static void __init zap_identity_mappings(void)
>> {
>> @@ -73,6 +74,11 @@ void __init x86_64_start_kernel(char * real_mode_data)
>> /* clear bss before set_intr_gate with early_idt_handler */
>> clear_bss();
>>
>> + /*
>> +* Load microcode early on BSP.
>> +*/
>> + load_ucode_bsp(real_mode_data);
>> +
>> /* Make NULL pointers segfault */
>> zap_identity_mappings();
>>
>
> So this patchset is after #PF handler set early page table version?
>
> then load_ucode_bsp() should be after
>
>load_idt((const struct desc_ptr *)_descr);
>
This patchset isn't before the #PF handler version (you can tell because
it has zap_identity_mappings()), but it does make sense to load the IDT
first.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fadvise: perform WILLNEED readahead in a workqueue
On Sun, Dec 16, 2012 at 05:23:02AM +, Eric Wong wrote: > Dave Chinner wrote: > > On Sun, Dec 16, 2012 at 03:35:49AM +, Eric Wong wrote: > > > Dave Chinner wrote: > > > > On Sun, Dec 16, 2012 at 12:25:49AM +, Eric Wong wrote: > > > > > Alan Cox wrote: > > > > > > On Sat, 15 Dec 2012 00:54:48 + > > > > > > Eric Wong wrote: > > > > > > > > > > > > > Applications streaming large files may want to reduce disk > > > > > > > spinups and > > > > > > > I/O latency by performing large amounts of readahead up front > > > > > This could also be a use case for an audio/video player. > > > > Sure, but this can all be handled by a userspace application. If you > > want to avoid/batch IO to enable longer spindown times, then you > > have to load the file into RAM somewhere, and you don't need special > > kernel support for that. > > From userspace, I don't know when/if I'm caching too much and possibly > getting the userspace cache itself swapped out. Which causes th disk to spin up. Now you start to see the complexity of what you are trying to acheive... > > > So no, there's no difference that matters between the approaches. > > > But I think doing this in the kernel is easier for userspace users. > > > > The kernel provides mechanisms for applications to use. You have not > > mentioned anything new that requires a new kernel mechanism to > > acheive - you just need to have the knowledge to put the pieces > > together properly. People have been solving this same problem for > > the last 20 years without needing to tweak fadvise(). Or even having > > an fadvise() syscall... > > fadvise() is fairly new, and AFAIK few apps use it. Perhaps if it > were improved, more people would use it and not have to reinvent > the wheel. fadvise() is not "fairly new". It's been around for many, many years - it was there whan the linux kernel moved to git in 2005, and I haven't bothered to look any further back in history... > > Nothing about low latency IO or streaming IO is simple or easy, and > > changing how readahead works doesn't change that fact. All it does > > is change the behaviour of every other application that uses > > fadvise() to minimise IO latency > > I don't want to introduce regressions, either. > > Perhaps if part of the FADV_WILLNEED read-ahead were handled > synchronously (maybe 2M?) and humongous large readaheads (like mine) > went to the background, that would be a good trade off? Which you can already do in userspace yourself without changing the kernel. i.e: main thread background thread: readahead(0, 2MB) spawn background thread read(0, len) readahead(2MB,1GB); Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] spi: devicetree: add support for loopback mode
On Sat, 15 Dec 2012 16:55:46 +0200, Felipe Balbi wrote: > On Sat, Dec 15, 2012 at 12:32:24AM +, Grant Likely wrote: > > On Wed, 12 Dec 2012 10:46:00 +0200, Felipe Balbi wrote: > > > there are a few spi master drivers which make > > > use of that flag but there is no way to pass it > > > through devicetree. > > > > > > This patch just creates a way to pass SPI_LOOP > > > via devicetree. > > > > I don't understand how this would be useful since loopback mode is > > really just a test feature. Is there any reason to do loopback for > > something other than test? > > > > I think it would be better to add a sysfs or debugfs property to > > manipulate the SPI_LOOP flag from userspace. What do you think? > > might be nicer in the long run, indeed. Want me to look into it, or do > you wanna do it yourself ? Yes, please look into it. After all, you're the one who needs the feature/ :-) g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pcmcia/vrc4171: Add missing spinlock init
It doesn't seem this spinlock was properly initialized. This bug was introduced by commit 7a410e8d4d97457c8c381e2de9cdc7bd3306badc. Signed-off-by: Jean Delvare --- I can't even build-test this. Already sent on: * 2012-09-06 drivers/pcmcia/vrc4171_card.c |1 + 1 file changed, 1 insertion(+) --- linux-3.6-rc4.orig/drivers/pcmcia/vrc4171_card.c2012-07-21 22:58:29.0 +0200 +++ linux-3.6-rc4/drivers/pcmcia/vrc4171_card.c 2012-09-06 14:07:40.976007788 +0200 @@ -246,6 +246,7 @@ static int pccard_init(struct pcmcia_soc socket = _sockets[slot]; socket->csc_irq = search_nonuse_irq(); socket->io_irq = search_nonuse_irq(); + spin_lock_init(>lock); return 0; } -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtc: imx dryice: Must include
Add the missing header include for spinlocks, to avoid potential build failures on specific architectures or configurations. Signed-off-by: Jean Delvare Acked-by: Sascha Hauer --- drivers/rtc/rtc-imxdi.c |1 + 1 file changed, 1 insertion(+) --- linux-3.8-rc0.orig/drivers/rtc/rtc-imxdi.c 2012-12-16 21:23:57.415274494 +0100 +++ linux-3.8-rc0/drivers/rtc/rtc-imxdi.c 2012-12-16 21:50:48.324778700 +0100 @@ -36,6 +36,7 @@ #include #include #include +#include #include /* DryIce Register Definitions */ -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PNP: Simplify setting of resources
On 15/12/12 01:17, Rafael J. Wysocki wrote: [snip] > Both patches queued up for submission as v3.8 material later in the cycle. Thanks! --- Witold > > Thanks, > Rafael > [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] swim: Add missing spinlock init
Hi Geert,
On Thu, 6 Sep 2012 14:03:27 +0200, Geert Uytterhoeven wrote:
> On Thu, Sep 6, 2012 at 1:48 PM, Jean Delvare wrote:
> > It doesn't seem this spinlock was properly initialized.
>
> Quiet possible. There's no SMP on m68k, so all spinlock ops expand to nothing.
Can we apply my patch still? Or were you suggesting you're fine with
the code as it is?
Certainly this isn't my area of expertise but I don't quite get the
point of passing a custom lock to blk_init_queue() if locks resolve to
nothing anyway.
> > Signed-off-by: Jean Delvare
> > Cc: Finn Thain
> > Cc: Geert Uytterhoeven
> > ---
> > I can't even build-test this.
> >
> > drivers/block/swim.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > --- linux-3.6-rc4.orig/drivers/block/swim.c 2012-07-21
> > 22:58:29.0 +0200
> > +++ linux-3.6-rc4/drivers/block/swim.c 2012-09-06 13:09:26.713382169 +0200
> > @@ -845,6 +845,7 @@ static int __devinit swim_floppy_init(st
> > swd->unit[drive].swd = swd;
> > }
> >
> > + spin_lock_init(>lock);
> > swd->queue = blk_init_queue(do_fd_request, >lock);
> > if (!swd->queue) {
> > err = -ENOMEM;
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ipu: Drop unused spinlock
On Fri, 14 Sep 2012 08:40:12 +0530, Vinod Koul wrote:
> On Thu, 2012-09-06 at 09:19 +0200, Jean Delvare wrote:
> > I was checking why this spinlock was never initialized, but it turns
> > out it's not used anywhere, so we can drop it.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Vinod Koul
> > Cc: Dan Williams
> > ---
> > I can't even build-test this.
> >
> > drivers/dma/ipu/ipu_irq.c |1 -
> > 1 file changed, 1 deletion(-)
> >
> > --- linux-3.6-rc4.orig/drivers/dma/ipu/ipu_irq.c2012-08-04
> > 21:49:26.0 +0200
> > +++ linux-3.6-rc4/drivers/dma/ipu/ipu_irq.c 2012-09-06 09:13:31.034228670
> > +0200
> > @@ -45,7 +45,6 @@ static void ipu_write_reg(struct ipu *ip
> > struct ipu_irq_bank {
> > unsigned intcontrol;
> > unsigned intstatus;
> > - spinlock_t lock;
> > struct ipu *ipu;
> > };
>
> Dan, you okay with this?
What happened to this patch? Dan, please?
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression] 3.7 ends in APIC panic
On Sun, Dec 16, 2012 at 08:46:06PM +0100, Bernd Schubert wrote: > Hmm, I read it the other way around - x2apic depends on interrupt > remapping, but interrupt remapping can be used without x2apic. Ok, you're right. X2APIC should depend on IRQ_REMAP: https://lwn.net/Articles/289881/ > The help text of CONFIG_IRQ_REMAP also says "x2APIC enhancements or to > support platforms with CPU's having > 8 bit APIC ID, say Y." I guess > may CPU has the latter? I think it is what Yinghai said - you obviously need x2apic kernel support if you have IRQ_REMAP on. > Can the kernel panic a bit improved to help user to understand what > needs to be enabled? Well, your kernel enables IRQ_REMAP properly: [0.031115] Enabled IRQ remapping in x2apic mode I guess at that stage we could probably check for x2apic support and scream loudly if it is not present... IMHO. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] fbdev changes for 3.8
* Tony Lindgren [121216 09:49]: > * Dave Jones [121215 14:27]: > > On Sat, Dec 15, 2012 at 01:11:04PM -0800, Linus Torvalds wrote: > > > On Fri, Dec 14, 2012 at 2:22 AM, Tomi Valkeinen > > wrote: > > > > Hi Linus, > > > > > > > > Florian, the fbdev maintainer, has been very busy lately, so I offered > > to send > > > > the pull request for fbdev for this merge window. > > > > > > Pulled. However, with this I get the Kconfig question > > > > > >OMAP2+ Display Subsystem support (OMAP2_DSS) [N/m/y/?] (NEW) > > > > > > which doesn't make a whole lot of sense on x86-64, unless there's > > > something about OMAP2 that I don't know. > > > > > > So I'd suggest making that OMAP2_DSS be dependent on OMAP2. Or at > > > least ARM. Because showing it to anybody else seems insane. > > > > > > Same goes for FB_OMAP2 for that matter. I realize that it's likely > > > nice to get compile testing for this on x86-64 too, but if that's the > > > intent, we need to think about it some more. I don't think it's good > > > to ask actual normal users questions like this just for compile > > > coverage. > > > > This OMAP stuff has been creeping into x86 builds for a while. > > Grep from my current build config .. > > > > # CONFIG_OMAP_OCP2SCP is not set > > # CONFIG_KEYBOARD_OMAP4 is not set > > # CONFIG_OMAP2_DSS is not set > > # CONFIG_OMAP_USB2 is not set > > > > There was some other arm-ism that does the same that I' currently > > forgetting, > > or maybe that got fixed.. > > Those are all omap internal devices and should be all marked with > depends on ARCH_OMAP2PLUS. > > It's a different story for external devices that may be used on other > architectures. > > I only came up with one reason to compile internal devices for other > architectures: In some cases the driver subsystem maintainer may want to > be able to compile test subsystem wide changes without having to compile > for each target separately. But for those cases it's trivial to carry a > compile test patch that just drops the depends Kconfig entries. And here's a patch to limit the omap drivers above to omap only. Regards, Tony From: Tony Lindgren Date: Sun, 16 Dec 2012 12:28:46 -0800 Subject: [PATCH] ARM: OMAP: Fix drivers to depend on omap for internal devices These devices are not available on other architectures, so let's limit them to omap. If the driver subsystem maintainers want to build test system wide changes without building for each target, it's easy to carry a test patch that just strips out the depends entries from Kconfig files. Signed-off-by: Tony Lindgren --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -6,6 +6,7 @@ menu "Bus devices" config OMAP_OCP2SCP tristate "OMAP OCP2SCP DRIVER" + depends on ARCH_OMAP2PLUS help Driver to enable ocp2scp module which transforms ocp interface protocol to scp protocol. In OMAP4, USB PHY is connected via --- a/drivers/input/keyboard/Kconfig +++ b/drivers/input/keyboard/Kconfig @@ -544,6 +544,7 @@ config KEYBOARD_OMAP config KEYBOARD_OMAP4 tristate "TI OMAP4+ keypad support" + depends on ARCH_OMAP2PLUS select INPUT_MATRIXKMAP help Say Y here if you want to use the OMAP4+ keypad. --- a/drivers/usb/phy/Kconfig +++ b/drivers/usb/phy/Kconfig @@ -6,6 +6,7 @@ comment "USB Physical Layer drivers" config OMAP_USB2 tristate "OMAP USB2 PHY Driver" + depends on ARCH_OMAP2PLUS select USB_OTG_UTILS help Enable this to support the transceiver that is part of SOC. This --- a/drivers/video/omap2/Kconfig +++ b/drivers/video/omap2/Kconfig @@ -1,6 +1,10 @@ config OMAP2_VRFB bool +if ARCH_OMAP2PLUS + source "drivers/video/omap2/dss/Kconfig" source "drivers/video/omap2/omapfb/Kconfig" source "drivers/video/omap2/displays/Kconfig" + +endif --- a/drivers/w1/masters/Kconfig +++ b/drivers/w1/masters/Kconfig @@ -60,6 +60,7 @@ config W1_MASTER_GPIO config HDQ_MASTER_OMAP tristate "OMAP HDQ driver" + depends on ARCH_OMAP help Say Y here if you want support for the 1-wire or HDQ Interface on an OMAP processor. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] ARM: Exynos5250: Enabling ehci-s5p driver
On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam
wrote:
> Adding EHCI device tree node for Exynos5250 along with
> the device base adress and gpio line for vbus.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 25
>
> arch/arm/boot/dts/exynos5250-smdk5250.dts |4 +++
> arch/arm/boot/dts/exynos5250.dtsi |6
> arch/arm/mach-exynos/include/mach/map.h|1 +
> arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
> 5 files changed, 38 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> new file mode 100644
> index 000..e8bbb47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -0,0 +1,25 @@
> +Samsung Exynos SoC USB controller
> +
> +The USB devices interface with USB controllers on Exynos SOCs.
> +The device node has following properties.
> +
> +EHCI
> +Required properties:
> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
> + EHCI controller in host mode.
> + - reg: physical base address of the controller and length of memory mapped
> + region.
> + - interrupts: interrupt number to the cpu.
> +
> +Optional properties:
> + - samsung,vbus-gpio: if present, specifies the GPIO that
> + needs to be pulled up for the bus to be powered.
> +
> +Example:
> +
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> index 711b55f..f990086 100644
> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
> @@ -218,4 +218,8 @@
> i2s_2: i2s@12D7 {
> status = "disabled";
> };
> +
> + usb@1211 {
> + samsung,vbus-gpio = < 6 1 3 3>;
> + };
> };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 581e57a..584bb9a 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -299,6 +299,12 @@
> rx-dma-channel = < 11>; /* preliminary */
> };
>
> + usb@1211 {
> + compatible = "samsung,exynos4210-ehci";
> + reg = <0x1211 0x100>;
> + interrupts = <0 71 0>;
> + };
> +
> amba {
> #address-cells = <1>;
> #size-cells = <1>;
> diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h
> index cbb2852..b2c662f 100644
> --- a/arch/arm/mach-exynos/include/mach/map.h
> +++ b/arch/arm/mach-exynos/include/mach/map.h
> @@ -201,6 +201,7 @@
> #define EXYNOS4_PA_EHCI 0x1258
> #define EXYNOS4_PA_OHCI 0x1259
> #define EXYNOS4_PA_HSPHY 0x125B
> +#define EXYNOS5_PA_EHCI 0x1211
> #define EXYNOS4_PA_MFC 0x1340
>
> #define EXYNOS4_PA_UART 0x1380
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index 462e5ac..b3b9af1 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -110,6 +110,8 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst = {
> "samsung-i2s.1", NULL),
> OF_DEV_AUXDATA("samsung,samsung-i2s", 0x12D7,
> "samsung-i2s.2", NULL),
> + OF_DEV_AUXDATA("samsung,exynos4210-ehci", EXYNOS5_PA_EHCI,
> + "s5p-ehci", NULL),
I'm assuming the above change is temporary. What is left to be done to
drop the auxdata in theses two patches?
Otherwise the patch looks fine.
Acked-by: Grant Likely
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
