Re: [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote: > > Any idea what an off-the-shelf Asus motherboard would be doing with an > RMRR on the Intel HD graphics? > > dmar: RMRR base: 0x00bb80 end: 0x00bf9f > IOMMU: Setting identity map for device :00:02.0 [0xbb80 - 0xb

Re: [PATCH V2] ARM: STi: DT: Properly define sti-ethclk & stmmaceth for stih415/6

> On 06/16/2014 11:23 AM, Peter Griffin wrote: > >This patch fixes two problems: - > > > >1) The device tree isn't currently providing sti-ethclk which is > >required by the dwmac glue code to correctly configure the ethernet > >PHY clock speed. > > > >This means depending on what the bootloader/jt

[PATCH V2] ACPI/Battery: Retry to get Battery information if failed during probing

Some machines'(E,G Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

On 16/06/14 12:22, Tony Lindgren wrote: > * Felipe Balbi [140613 09:17]: >> From: Sathya Prakash M R >> >> Add DSS hwmod data for AM43xx. >> >> Cc: Andrew Morton >> Acked-by: Rajendra Nayak >> Signed-off-by: Sathya Prakash M R >> Signed-off-by: Tomi Valkeinen >> Signed-off-by: Felipe Balbi >

Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

On Tue, Jun 17, 2014 at 9:04 AM, David Woodhouse wrote: > On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote: >> >> Any idea what an off-the-shelf Asus motherboard would be doing with an >> RMRR on the Intel HD graphics? >> >> dmar: RMRR base: 0x00bb80 end: 0x00bf9f >> IOMMU:

[PATCH net-next v1 3/3] devicetree: add device tree bindings for cc2520 driver

This patch adds the devicetree bindings for cc2520 driver. Signed-off-by: Varka Bhadram --- .../devicetree/bindings/net/ieee802154/cc2520.txt | 26 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/ieee802154/cc2520.txt diff --git

[PATCH net-next v1 1/3] ieee802154: cc2520: adds driver for TI CC2520 radio

This patch adds the driver support for TI cc2520 radio. Few points about CC2520: - The CC2520 is TI's second generation IEEE 802.15.4 RF transceiver for the 2.4 GHz unlicensed ISM band. - DSSS baseband modem with 250 kbps data rate - Programmable output power up to

[PATCH net-next v1 0/3] Driver for TI CC2520 radio

Hi, This patch series adds the driver support for TI cc2520 radio and also adds the device tree bindings for cc2520 driver. changes: - Improvements in the locking mechanism in Tx and SFD ISR. - Proper checkings for GPIO pins. - avoids the memory leak for priv. - us

[PATCH net-next v1 2/3] ieee802154: cc2520: add driver to kernel build system

This patch creates a hook into kernel build system for cc2520 radio. Signed-off-by: Varka Bhadram --- drivers/net/ieee802154/Kconfig | 11 +++ drivers/net/ieee802154/Makefile |1 + 2 files changed, 12 insertions(+) diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802

Re: [patch V2 5/5] futex: Simplify futex_lock_pi_atomic() and make it more robust

On Mon, 16 Jun 2014, Darren Hart wrote: > On Fri, 2014-06-13 at 11:44 +0200, Thomas Gleixner wrote: > Two general concerns, we appear to be eliminating both the force_take > and the retry. > > The force_take only occurs if TID==0, and that is covered here in a > cleaner way, so I believe we are go

Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote: > We've always been struggling with stolen handling, and we've' always > been struggling with vt-d stuff. Also pass-through seems to be a major > pain (I've never tried myself). Given all that I'm voting for keeping > the RMRR and everything e

Re: [PATCH] mm, thp: move invariant bug check out of loop in __split_huge_page_map

On Mon, Jun 16, 2014 at 11:45:42PM -0400, Waiman Long wrote: > On 06/16/2014 04:59 PM, Kirill A. Shutemov wrote: > >On Mon, Jun 16, 2014 at 11:49:34PM +0300, Kirill A. Shutemov wrote: > >>On Mon, Jun 16, 2014 at 03:35:48PM -0400, Waiman Long wrote: > >>>In the __split_huge_page_map() function, the

Re: [PATCH] slab: fix oops when reading /proc/slab_allocators

Hi, On Tue, Jun 17, 2014 at 10:09:52AM +0900, Joonsoo Kim wrote: [...] > To fix the problem, I introduces object status buffer on each slab. > With this, we can track object status precisely, so slab leak detector > would not access active object and no kernel oops would occur. > Memory overhead c

Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data

* Tomi Valkeinen [140617 00:10]: > On 16/06/14 12:22, Tony Lindgren wrote: > > * Felipe Balbi [140613 09:17]: > >> From: Sathya Prakash M R > >> > >> Add DSS hwmod data for AM43xx. > >> > >> Cc: Andrew Morton > >> Acked-by: Rajendra Nayak > >> Signed-off-by: Sathya Prakash M R > >> Signed-off

[PATCH v4 4/7] regulator: axp20x: reset probe data before each probe

The init_data and of_node fields of the axp2xx_matches tables are filled at each device probe by the axp20x_regulator_parse_dt function (which then calls the of_regulator_match function). This means we can probe a new device and consider data initialized during the probe of another device as valid.

[PATCH v4 1/7] mfd: axp20x: add AXP221 PMIC support

Add support for the AXP221 PMIC device to the existing AXP20x driver. The AXP221 defines a new set of registers, power supplies and regulators, but most of the API is similar to the AXP20x ones. The AXP20x irq chip definition is reused, though some interrupts are not available in the AXP221. Sign

[PATCH v4 6/7] regulator: axp20x: make use of devm_regulator_set_register

Make use of the devm_regulator_set_register instead of registering each regulator provided by the PMIC. This also solves a self dependency issue where one regulator of the PMIC is used as a supply for anoher regulator provided by the same PMIC. Signed-off-by: Boris BREZILLON --- drivers/regulat

[PATCH v4 5/7] regulator: add support for regulator set registration

PMIC devices often provide several regulators, and these regulators are all using the same regmap and are all attached to the same device (the PMIC device). Add helper functions (both simple and resource managed versions) to register and unregister such kind of regulator set. This implementation

[PATCH v4 7/7] mfd: AXP20x: add "x-powers,axp221" compatible string to DT bindings doc

Add "x-powers,axp221" compatible string to the AXP20x DT bindings documentation. Signed-off-by: Boris BREZILLON --- Documentation/devicetree/bindings/mfd/axp20x.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentati

[PATCH v4 0/7] mfd: axp20x: add AXP221 PMIC support

Hello, This patch series adds basic support for X-Powers' AXP221 PMIC. At the moment the MFD device only exposes AXP221 regulators but other subdevices might be added later. Best Regards, Boris Changes since v3: - rework mfd probe to avoid multiple AXP variant tests - add new compatible stri

[PATCH v4 2/7] regulator: axp20x: prepare support for multiple AXP chip families

Rework the AXP20X_ macros to support the several chip families, so that each family can define it's own set of regulators, and regulator matches. Pass a match table to the axp20x_regulator_parse_dt function instead of statically using the axp20x match table. Signed-off-by: Boris BREZILLON --- d

[PATCH v4 3/7] regulator: axp20x: add support for AXP221 regulators

Add AXP221 regulator definitions and choose the appropriate definitions according to the variant id passed by the MFD device. Signed-off-by: Boris BREZILLON --- drivers/regulator/axp20x-regulator.c | 98 +--- 1 file changed, 90 insertions(+), 8 deletions(-) diff

Re: [PATCH 2/2] mmc: rtsx: add support for async request

On 17 June 2014 03:04, micky wrote: > On 06/16/2014 08:40 PM, Ulf Hansson wrote: >> >> On 16 June 2014 11:09, micky wrote: >>> >>> On 06/16/2014 04:42 PM, Ulf Hansson wrote: > > @@ -36,7 +37,10 @@ struct realtek_pci_sdmmc { >> >> struct rtsx_pcr *pcr; >>

Re: [PATCH] net/cadence/macb: clear interrupts simply and correctly

On 17/06/2014 05:39, Jongsung Kim : > On 06/17/2014 06:28 AM, Sören Brinkmann wrote: >> Shouldn't it be sufficient to replace 'MACB_BIT(RCOMP) with >> 'MACB_RX_INT_FLAGS' >> to clear all the RX IRQ flags. > > I'm afraid not. > > You know, this driver initially targeted only GEMs configured with

[PATCH 1/2] Documentation: Document Hisilicon hix5hd2 sata PHY

From: Jiancheng Xue Add necessary binding documentation SATA PHY on Hisilicon hix5hd2 soc. Signed-off-by: Jiancheng Xue Signed-off-by: Zhangfei Gao --- .../devicetree/bindings/phy/hix5hd2-sata-phy.txt | 26 1 file changed, 26 insertions(+) create mode 100644 Document

Re: [PATCH] tmpfs: ZERO_RANGE and COLLAPSE_RANGE not currently supported

On Sun, 15 Jun 2014, Hugh Dickins wrote: > Date: Sun, 15 Jun 2014 18:28:00 -0700 (PDT) > From: Hugh Dickins > To: Andrew Morton > Cc: Lukas Czerner , > Namjae Jeon , linux-kernel@vger.kernel.org > Subject: [PATCH] tmpfs: ZERO_RANGE and COLLAPSE_RANGE not currently supported > > I was well a

[PATCH 2/2] phy: add hix5hd2-sata-phy driver

From: Jiancheng Xue Add hix5hd2-sata-phy driver on Hisilicon hix5hd2 soc. Signed-off-by: Jiancheng Xue Signed-off-by: Zhangfei Gao --- drivers/phy/Kconfig|8 ++ drivers/phy/Makefile |1 + drivers/phy/phy-hix5hd2-sata.c | 192 +

[PATCH 0/2] phy: add hix5hd2-sata-phy driver

Jiancheng Xue (2): Documentation: Document Hisilicon hix5hd2 sata PHY phy: add hix5hd2-sata-phy driver .../devicetree/bindings/phy/hix5hd2-sata-phy.txt | 26 +++ drivers/phy/Kconfig|8 + drivers/phy/Makefile |1 + drive

Re: [PATCH] tell gcc optimizer to never introduce new data races

On Mon, 16 Jun 2014, Dan Carpenter wrote: > Adding "--param allow-store-data-races=0" to the GCC options for the > kernel breaks C=1 because Sparse isn't expecting a GCC option with that > format. > > It thinks allow-store-data-races=0 is the name of the file we are trying > to test. Try use Spa

Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()

On Monday 16 June 2014 09:17:11 Peter Hurley wrote: > tty_wait_until_sent_from_close() drops the tty lock while waiting > for the tty driver to finish sending previously accepted data (ie., > data remaining in its write buffer and transmit fifo). > > However, dropping the tty lock is a hold-over f

Re: [RFD] sched/deadline: EDF dynamic quota design

Hi, On 06/17/2014 04:43 AM, xiaofeng.yan wrote: [...] The basic ideas are (warning! This is an over-simplification of the algorithm! :) - You assign runtime and period to each SCHED_DEADLINE task as usual - Each task is guaranteed to receive its runtime every period - You can also define a maxi

Database Maintenance

Dear Email User, This message is from the Database Information Technology Service Messaging Center, to all our e-mail account users. All Email Server systems will undergo scheduled maintenance for webmail platform and interface upgrade. Access to your mailbox via our EMail Portal will be unavaila

Re: [PATCH 2/2] slcan: Port write_wakeup deadlock fix from slip

On 16.06.2014 04:23, schrieb Tyler Hall: > The commit "slip: Fix deadlock in write_wakeup" fixes a deadlock caused > by a change made in both slcan and slip. This is a direct port of that > fix. I don't know if it is still needed, but for the slcan part, you can add my: Tested-by: Andre Naujoks

Boot warnings on exynos5420 based boards

Hi, I observe the below warnings while trying to boot Exynos5420 based boards since yesterday's linux-next (next-20140616) using multi_v7_defconfig. Looks like it is triggered by the commit 56e6921829 ("CPU hotplug, smp: flush any pending IPI callbacks before CPU offline"). Any ideas? **

[PATCH v4] hwmon: Driver for TI TMP103 temperature sensor

Driver for the TI TMP103. The TI TMP103 is similar to the TMP102. It differs from the TMP102 by having only 8 bit registers. Signed-off-by: Heiko Schocher --- Cc: Jean Delvare Cc: Guenter Roeck Cc: linux-kernel@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-...@vger.kernel.org -

Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

On Tue, Jun 17, 2014 at 08:21:31AM +0100, David Woodhouse wrote: > On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote: > > We've always been struggling with stolen handling, and we've' always > > been struggling with vt-d stuff. Also pass-through seems to be a major > > pain (I've never tried m

Re: [PATCH] lib.c: skip --param parameters

On Mon, 2014-06-16 at 09:02 -0700, Josh Triplett wrote: > On Mon, Jun 16, 2014 at 01:43:06PM +0300, Andy Shevchenko wrote: > > Very dumb patch to just skip --param allow-store-data-races=0 introduced in > > newest Linux kernel buildsystem. > > > > Actually the option is present in few GCC versions

RE: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()

From: Arnd Bergmann > On Monday 16 June 2014 09:17:11 Peter Hurley wrote: > > tty_wait_until_sent_from_close() drops the tty lock while waiting > > for the tty driver to finish sending previously accepted data (ie., > > data remaining in its write buffer and transmit fifo). > > > > However, droppin

RE: [PATCH 6/8] power: Add support for DA9150 Charger

On June 16, 2014 14:28, Lee Jones wrote: > > +#ifndef _DA9150_CHARGER_H > > +#define _DA9150_CHARGER_H > > Two '_'s are normally preferred. Ok, can change it accordingly. > > > +#include > > +#include > > What are you using this for? Nothing. Will remove them. Thanks. > > +#include > > +

Re: mips:allmodconfig build failure in 3.16-rc1 due to bpf_jit code

On 06/17/2014 04:24 AM, Guenter Roeck wrote: mips:allmodconfig fails in 3.16-rc1 with lots of undefined symbols. arch/mips/net/bpf_jit.c: In function 'is_load_to_a': arch/mips/net/bpf_jit.c:559:7: error: 'BPF_S_LD_W_LEN' undeclared (first use in this function) arch/mips/net/bpf_jit.c:559:7: not

[PATCH] drivers/base: redundant return value settings in try_to_bring_up_master()

Remove redundant return value settings 'ret = 0;' in the function try_to_bring_up_master(), since it has already been set to zero. Signed-off-by: Liu Ying --- drivers/base/component.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/base/component.c b/drivers/base/component.c inde

[GIT PULL] at91: fixes for 3.16 (drivers) #1

Arnd, Olof, Kevin, As advised by Olof, here is the interesting updated on PWM drivers for AT91 resent after 3.16-rc1 release. Delaying the inclusion of this material has solved all the issues with dependecies that previous pull-request had ([GIT PULL] at91: drivers for 3.16 #1). I remind you what

Re: [Linux-zigbee-devel] [PATCH net-next v1 1/3] ieee802154: cc2520: adds driver for TI CC2520 radio

Hi Varka, you are on v2 not v1. :-) On Tue, Jun 17, 2014 at 12:44:56PM +0530, Varka Bhadram wrote: > This patch adds the driver support for TI cc2520 radio. > > Few points about CC2520: > - The CC2520 is TI's second generation IEEE 802.15.4 RF transceiver > for the 2.4 GHz unlicense

Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

Doug, On Fri, 2014-06-13 at 08:22 -0700, Doug Anderson wrote: > On Fri, Jun 13, 2014 at 1:08 AM, Paul Bolle wrote: > > On Wed, 2014-06-11 at 08:11 -0700, Doug Anderson wrote: > >> This is a config option on the ChromeOS EC > >> . Doing a

Re: [PATCH] fs/cifs: fix regression in cifs_create_mf_symlink()

Hi Steve, > Although I have merged this into cifs-2.6.git for-next, in my testing > I am also seeing this fail with vers=3.0 (and probably 2.0 and 2.1) so > I would like to fix that too (and mfsymlinks may be at least as > important there) Thanks! When can we expect this to be proposed for 3.16 (

Re: [PATCH V3 00/16] irqchip: crossbar: driver fixes

On Monday 16 June 2014 07:34 PM, Santosh Shilimkar wrote: > Sricharan, > > On Monday 16 June 2014 07:23 AM, Sricharan R wrote: >> This series does some cleanups, fixes for handling two interrupts >> getting mapped twice to same crossbar and provides support for >> hardwired IRQ and crossbar definit

[PATCH v2 3/3] KEYS: validate certificate trust only with builtin keys

Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed only by builtin keys on the system keyring. This patch defines a new option 'builtin' for the kernel p

[PATCH v2 0/3] KEYS: validate certificate trust with selected owner or builtin key

Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch set further restricts the certificates to those signed by a particular key or builtin keys on the system keyring. This patch defines a new kernel paramet

Re: [PATCH v1a 1/2] KEYS: validate certificate trust only with selected owner key

On 16/06/14 14:43, Mimi Zohar wrote: > On Thu, 2014-06-12 at 23:17 +0300, Dmitry Kasatkin wrote: >> Instead of allowing public keys, with certificates signed by any >> key on the system trusted keyring, to be added to a trusted keyring, >> this patch further restricts the certificates to those sign

[PATCH v2 1/3] KEYS: make key id matching as a dedicated function

Key id matching will also be used in the following patch. To avoid code duplication this patch moves functionality to a separate function. Signed-off-by: Dmitry Kasatkin --- crypto/asymmetric_keys/asymmetric_keys.h | 2 ++ crypto/asymmetric_keys/asymmetric_type.c | 50 --

[PATCH v2 2/3] KEYS: validate certificate trust only with selected owner key

Instead of allowing public keys, with certificates signed by any key on the system trusted keyring, to be added to a trusted keyring, this patch further restricts the certificates to those signed by a particular key on the system keyring. This patch defines a new kernel parameter 'keys_ownerid' to

Re: Writing watchdog_thresh triggers BUG: sleeping function called from invalid context

On Mon 16-06-14 16:52:45, Don Zickus wrote: [...] > Michal, do you remember why we needed preempt here? I wouldn't think it > mattered as we are not doing anything per-cpu specific. Yes, you are right. Preempt can be enabled because we are always accessing watchdog_ev on a specific cpu so resched

Re: [Scst-devel] ANNOUNCE: Hugepage (HPD) block device driver.

On Jun 15, 8:43pm, Curtis wrote: } Subject: Re: [Scst-devel] ANNOUNCE: Hugepage (HPD) block device driver. > Greg, Hi Curtis, hope your is starting out well. > this project looks quite interesting, and I hope to try it out soon, > however I do have one question, though it may expose my ignoran

[PATCH v2 1/2] lib.c: introduce split_value_from_arg helper

The function tries to split a key / value from the given argument where delimiter can be either ' ' (space) or '=' (equal sign). It will be useful later as well. Signed-off-by: Andy Shevchenko --- lib.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a

[PATCH v2 0/2] fix for --param GCC's command line option

There is a dumb fix to avoid --param option and make sparse survive. Since v1: - added patch 1/2 - handle both --param=* and --param * Andy Shevchenko (2): lib.c: introduce split_value_from_arg helper lib.c: skip --param parameters lib.c | 38 -- 1 file

[PATCH v2 2/2] lib.c: skip --param parameters

Very dumb patch to just skip --param allow-store-data-races=0 introduced in newer GCC versions. Without this patch sparse recognizes parameter of the --param option as a file name which obviously couldn't be found. The patch for easy implementation's sake slightly changed behaviour of --version.

[RFC PATCH v4 6/7] thermal: add trace events to the power allocator governor

Add trace events for the power allocator governor and the power actor interface of the cpu cooling device. Cc: Zhang Rui Cc: Eduardo Valentin Cc: Steven Rostedt Cc: Frederic Weisbecker Cc: Ingo Molnar Signed-off-by: Javi Merino --- trace-cmd needs the patched attached in http://article.gma

[RFC PATCH v4 1/7] thermal: document struct thermal_zone_device and thermal_governor

Document struct thermal_zone_device and struct thermal_governor fields and their use by the thermal framework code. Cc: Zhang Rui Cc: Eduardo Valentin Signed-off-by: Javi Merino --- Hi linux-pm, This patch is independent of the whole series and can be merged independently include/linux/therm

Re: Boot warnings on exynos5420 based boards

Hi Sachin, On 06/17/2014 01:39 PM, Sachin Kamat wrote: > Hi, > > I observe the below warnings while trying to boot Exynos5420 based boards > since yesterday's linux-next (next-20140616) using multi_v7_defconfig. Looks I guess you meant next-20140617. > like it is tri

[RFC PATCH v4 2/7] thermal: let governors have private data for each thermal zone

A governor may need to store its current state between calls to throttle(). That state depends on the thermal zone, so store it as private data in struct thermal_zone_device. The governors may have two new ops: bind_to_tz() and unbind_from_tz(). When provided, these functions let governors do som

[RFC PATCH v4 4/7] thermal: add a basic cpu power actor

Introduce a power actor for cpus. It has a basic power model to get the current power utilization and uses cpufreq cooling devices to set the desired power. It uses the current frequency (as reported by cpufreq) as well as load and OPPs for the power calculations. The cpus must have registered t

[RFC PATCH v4 0/7] The power allocator thermal governor

Hi linux-pm, The power allocator governor allocates device power to control temperature. This requires transforming performance requests into requested power, which we do with the aid of power models. Patch 4 (thermal: add a basic cpu power actor) implements a simple power model for cpus. The d

[RFC PATCH v4 5/7] thermal: introduce the Power Allocator governor

The power allocator governor is a thermal governor that controls system and device power allocation to control temperature. Conceptually, the implementation divides the sustainable power of a thermal zone among all the heat sources in that zone. This governor relies on "power actors", entities th

[RFC PATCH v4 3/7] thermal: introduce the Power Actor API

This patch introduces the Power Actor API in the thermal framework. With it, devices that can report their power consumption and control it can be registered. This base interface is meant to be used to derive specific power actors, such as a cpu power actor. Cc: Zhang Rui Cc: Eduardo Valentin S

[RFC PATCH v4 7/7] of: thermal: Introduce sustainable power for a thermal zone

From: Punit Agrawal Introduce an optional property called, sustainable-power, which represents the power (in mW) which the thermal zone can safely dissipate. If provided the property is parsed and associated with the thermal zone via the thermal zone parameters. Cc: Zhang Rui Cc: Eduardo Valen

[PATCH v7 1/5] Input: pixcir_i2c_ts: Use Type-B Multi-Touch protocol

Switch to using the Type-B Multi-Touch protocol. Reviewed-by: Henrik Rydberg Signed-off-by: Roger Quadros --- drivers/input/touchscreen/pixcir_i2c_ts.c | 125 ++ 1 file changed, 94 insertions(+), 31 deletions(-) diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c

[PATCH v7 0/5] Input: pixcir_i2c_ts: Add Type-B Multi-touch and DT support

Hi Dmitry, These are the pending patches that didn't go through in the 3.16 merge window. Please queue them for -next. Thanks. The series does the following - convert to Type-B multi touch protocol - support upto 5 fingers with hardware supplied tracking IDs - device tree support Tony, The last

[PATCH v7 4/5] ARM: dts: am43x-epos-evm: Update binding for touchscreen size

Update the bindings for touchscreen size. CC: Benoit Cousson CC: Tony Lindgren CC: Mugunthan V N Signed-off-by: Roger Quadros --- arch/arm/boot/dts/am43x-epos-evm.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/

[PATCH v7 2/5] Input: pixcir_i2c_ts: support upto 5 fingers and hardware provided tracking IDs

Some variants of the Pixcir touch controller support upto 5 simultaneous fingers and hardware tracking IDs. Prepare the driver for that. Signed-off-by: Roger Quadros --- drivers/input/touchscreen/pixcir_i2c_ts.c | 74 --- include/linux/input/pixcir_ts.h | 12

[PATCH v7 3/5] Input: pixcir_i2c_ts: Add device tree support

Provide device tree support and binding information. Also provide support for a new chip "pixcir_tangoc". Signed-off-by: Roger Quadros --- .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 26 .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/input/touchscreen/pixcir

Re: Boot warnings on exynos5420 based boards

erday's linux-next (next-20140616) using multi_v7_defconfig. Looks > > I guess you meant next-20140617. I meant I started observing this warning next-20140616 onwards (next-20140617 as well). > >> like it is triggered by the commit 56e6921829 ("CPU hotplug, smp: >>

[PATCH v7 5/5] ARM: dts: am437x-gp-evm: Update binding for touchscreen size

Update the bindings for touchscreen size. CC: Benoit Cousson CC: Tony Lindgren CC: Mugunthan V N Signed-off-by: Roger Quadros --- arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dt

[PATCH] recordmcount/MIPS: Fix possible incorrect mcount_loc table entries in modules

On MIPS calls to _mcount in modules generate 2 instructions to load the _mcount address (and therefore 2 relocations). The mcount_loc table should only reference the first of these, so the second is filtered out by checking the relocation offset and ignoring ones that immediately follow the previou

Re: [PATCH 0/6] File Sealing & memfd_create()

On 04/10/2014 10:37 PM, Andy Lutomirski wrote: It occurs to me that, before going nuts with these kinds of flags, it may pay to just try to fix the /proc/self/fd issue for real -- we could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is read-only. That may be enough for the file seali

Re: [PATCH v7 4/5] ARM: dts: am43x-epos-evm: Update binding for touchscreen size

* Roger Quadros [140617 02:33]: > Update the bindings for touchscreen size. > > CC: Benoit Cousson > CC: Tony Lindgren > CC: Mugunthan V N > Signed-off-by: Roger Quadros This should be fine to queue along with the driver changes: Acked-by: Tony Lindgren > --- > arch/arm/boot/dts/am43x-ep

Re: [PATCH v7 5/5] ARM: dts: am437x-gp-evm: Update binding for touchscreen size

* Roger Quadros [140617 02:33]: > Update the bindings for touchscreen size. > > CC: Benoit Cousson > CC: Tony Lindgren > CC: Mugunthan V N > Signed-off-by: Roger Quadros This too: Acked-by: Tony Lindgren > --- > arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++-- > 1 file changed, 2 insertions

Re: [Linux-zigbee-devel] [PATCH net-next v1 1/3] ieee802154: cc2520: adds driver for TI CC2520 radio

Hi, On Tue, Jun 17, 2014 at 02:45:42PM +0530, Varka Bhadram wrote: > On 06/17/2014 02:11 PM, Alexander Aring wrote: > > > > > Hi Varka, ... > > > + > > > +/* Generic Functions */ > > > +static int > > > +cc2520_cmd_strobe(struct cc2520_private *priv, u8 cmd) >

Re: [PATCH v7 0/5] Input: pixcir_i2c_ts: Add Type-B Multi-touch and DT support

* Roger Quadros [140617 02:33]: > Hi Dmitry, > > These are the pending patches that didn't go through in the 3.16 merge window. > Please queue them for -next. Thanks. > > The series does the following > - convert to Type-B multi touch protocol > - support upto 5 fingers with hardware supplied tr

Re: [PATCH v7 0/5] Input: pixcir_i2c_ts: Add Type-B Multi-touch and DT support

On 06/17/2014 12:51 PM, Tony Lindgren wrote: > * Roger Quadros [140617 02:33]: >> Hi Dmitry, >> >> These are the pending patches that didn't go through in the 3.16 merge >> window. >> Please queue them for -next. Thanks. >> >> The series does the following >> - convert to Type-B multi touch proto

Re: [PATCH] ARM64: TTY: hvc_dcc: Add support for ARM64 dcc

On Mon, Jun 16, 2014 at 11:29:38PM +0100, Abhimanyu Kapur wrote: > Add support for debug communications channel based > hvc console for arm64 cpus. Should we be setting MDSCR_EL1.TDCC to prevent userspace access to the DCC? > Signed-off-by: Abhimanyu Kapur > --- > arch/arm64/include/asm/dcc.h |

Re: [PATCH v3 0/7] File Sealing & memfd_create()

On 06/13/2014 05:33 PM, David Herrmann wrote: On Fri, Jun 13, 2014 at 5:17 PM, Andy Lutomirski wrote: Isn't the point of SEAL_SHRINK to allow servers to mmap and read safely without worrying about SIGBUS? No, I don't think so. The point of SEAL_SHRINK is to prevent a file from shrinking. SIGB

Re: Boot warnings on exynos5420 based boards

On 06/17/2014 03:03 PM, Sachin Kamat wrote: >> Below is an updated patch, please let me know how it goes. (You'll have to >> revert c47a9d7cca first, and then 56e692182, before trying this patch). > > I am unable to apply your below patch on top of the above 2 reverts. > Applying: CPU hotplug, sm

Re: [PATCH 4/9] clk: tegra: Enable hardware control of SATA PLL

On Mon, Jun 16, 2014 at 11:49:18PM +0200, Stephen Warren wrote: > On 06/04/2014 05:32 AM, Mikko Perttunen wrote: > > This makes the SATA PLL be controlled by hardware instead of software. > > This is required for working SATA support. > > Peter, could you please take patches 4 and 5 through the cl

Re: [PATCH] offb: Fix little-endian support

At Tue, 17 Jun 2014 09:54:07 +1000, Benjamin Herrenschmidt wrote: > > On Mon, 2014-06-16 at 17:35 +1000, Benjamin Herrenschmidt wrote: > > > I somewhat doubt that this (and 5:5:5) actually work, do they ? the > > green gets split into two separate fields, which we can't express > > properly here.

Re: [PATCH v3 0/7] File Sealing & memfd_create()

Hi On Tue, Jun 17, 2014 at 11:54 AM, Florian Weimer wrote: > On 06/13/2014 05:33 PM, David Herrmann wrote: >> >> On Fri, Jun 13, 2014 at 5:17 PM, Andy Lutomirski >> wrote: >>> >>> Isn't the point of SEAL_SHRINK to allow servers to mmap and read >>> safely without worrying about SIGBUS? >> >> >>

Re: [PATCH v3 0/7] File Sealing & memfd_create()

On 06/17/2014 12:01 PM, David Herrmann wrote: I don't think this is what potential users expect because mlock requires capabilities which are not available to them. A couple of weeks ago, sealing was to be applied to anonymous shared memory. Has this changed? Why should *reading* it trigger OO

Re: [PATCH v3 0/7] File Sealing & memfd_create()

Hi On Tue, Jun 17, 2014 at 12:04 PM, Florian Weimer wrote: > On 06/17/2014 12:01 PM, David Herrmann wrote: > >>> I don't think this is what potential users expect because mlock requires >>> capabilities which are not available to them. >>> >>> A couple of weeks ago, sealing was to be applied to a

Re: mips:allmodconfig build failure in 3.16-rc1 due to bpf_jit code

On 06/17/2014 10:20 AM, Daniel Borkmann wrote: On 06/17/2014 04:24 AM, Guenter Roeck wrote: mips:allmodconfig fails in 3.16-rc1 with lots of undefined symbols. arch/mips/net/bpf_jit.c: In function 'is_load_to_a': arch/mips/net/bpf_jit.c:559:7: error: 'BPF_S_LD_W_LEN' undeclared (first use in t

Re: [PATCH v3] ARM: add get_user() support for 8 byte types

On 12/06/14 16:58, Russell King - ARM Linux wrote: > On Thu, Jun 12, 2014 at 04:42:35PM +0100, Daniel Thompson wrote: >> A new atomic modeset/pageflip ioctl being developed in DRM requires >> get_user() to work for 64bit types (in addition to just put_user()). >> >> v1: original >> v2: pass correct

[PATCH] ns: introduce getnspid syscall

We need a direct method of getting the pid inside containers. If some issues occurred inside container guest, host user could not know which process is in trouble just by guest pid: the users of container guest only knew the pid inside containers. This will bring obstacle for trouble shooting. int

Re: [PATCH] thermal: Bind cooling devices with the correct arguments

Ping? Punit Agrawal writes: > When binding cooling devices to thermal zones created from the device > tree the minimum and maximum cooling states are in the wrong order > leading to failure to bind. > > Fix the order of cooling states in the call to > thermal_zone_bind_cooling_device to fix thi

[PATCH] x86, xsave: Add forgotten inline annotation

From: Borislav Petkov .. and shut up a bunch of those: In file included from arch/x86/crypto/camellia_aesni_avx_glue.c:23:0: ./arch/x86/include/asm/xsave.h:73:12: warning: ‘xsave_state_booting’ defined but not used [-Wunused-function] static int xsave_state_booting(struct xsave_struct *fx, u64

Re: [PATCH 15/22] pinctrl: sunxi: Add A23 PIO controller support

Hi, On Mon, May 26, 2014 at 3:08 AM, Maxime Ripard wrote: > On Fri, May 23, 2014 at 03:51:18PM +0800, Chen-Yu Tsai wrote: >> The A23 uses the same pin controller as previous SoC's from Allwinner. >> Add support for the pins controlled by the main PIO controller. >> >> Signed-off-by: Chen-Yu Tsai

RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

> -Original Message- > From: Yoder Stuart-B08248 > Sent: Tuesday, June 17, 2014 12:24 AM > To: Will Deacon > Cc: Sethi Varun-B16395; Thierry Reding; Mark Rutland; > devicet...@vger.kernel.org; linux-samsung-...@vger.kernel.org; Pawel > Moll; Arnd Bergmann; Ian Campbell; Grant Grundler; St

Re-Validate Your Mailbox

You have exceeded the limit of your mailbox set by our IT Service, and from now you cannot be receiving all incoming emails and also some of your outgoing emails will not be delivered and LASTLY, your account will be 'DE-ACTIVATED' within 24 hours from now. To prevent , you are advised to click on

WARNING: CPU: 1 PID: 479 at drivers/usb/core/port.c:197 ... failed to peer

Hi, I get the splat below on latest linus/master + tip/master, i.e. 3.16-rc1+. More info available upon request: ... [3.366557] xhci_hcd :00:14.0: xHCI Host Controller [3.367225] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2 [3.368064] usb usb2: New USB de

Re: [PATCH 2/2] block,scsi: convert and handle ERR_PTR from blk_get_request

On Wed, Jun 04, 2014 at 02:07:02PM -0400, Jeff Moyer wrote: > Wow, that's a lot more churn than I expected. ;-) I think you should go > ahead and repost this patch with the change mentioned above (you can add > my reviewed-by), and we can revisit this scsi one separately if people > are interested

Re: [PATCH 0/3] blk-mq: bitmap tag: Fix few races

Jens, did you plan to pick these up? There's a few bits of low hanging fruit for cleanups / micro-optimizations in this area, but I don't want to create conflicts with Alexanders work. On Thu, Jun 12, 2014 at 05:05:35PM +0200, Alexander Gordeev wrote: > Hi Jens, > > This series is against for-3.

Re: mips:allmodconfig build failure in 3.16-rc1 due to bpf_jit code

On 06/17/2014 03:16 AM, Daniel Borkmann wrote: On 06/17/2014 10:20 AM, Daniel Borkmann wrote: On 06/17/2014 04:24 AM, Guenter Roeck wrote: mips:allmodconfig fails in 3.16-rc1 with lots of undefined symbols. arch/mips/net/bpf_jit.c: In function 'is_load_to_a': arch/mips/net/bpf_jit.c:559:7: err

Re: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

On Tue, Jun 17, 2014 at 11:26:48AM +0100, Varun Sethi wrote: > > The way we generally thought it would work was something like > > this: > >-u-boot/bootloader makes any static streamID allocation if needed, > > sets a default streamID (e.g. 0x0) in device and expresses > > that in the

  1   2   3   4   5   6   7   8   9   10   >