Allocate a separate structure for the vm86 fields.
Signed-off-by: Brian Gerst
---
arch/x86/include/asm/processor.h | 11 +++---
arch/x86/include/asm/vm86.h | 19 -
arch/x86/kernel/process.c| 3 +++
arch/x86/kernel/vm86_32.c| 46 +++---
On Mon, 2015-07-27 at 16:49 +0100, Robin Murphy wrote:
> On 27/07/15 16:31, Russell King - ARM Linux wrote:
> > On Mon, Jul 27, 2015 at 02:23:26PM +0100, Robin Murphy wrote:
> >> On 16/07/15 10:04, Yong Wu wrote:
> >>> This patch adds support for mediatek m4u (MultiMedia Memory Management
> >>> Uni
Takao Indoh writes:
> Hi all,
>
> This patch creates log buffer for Intel PT and enable logging at boot
> time. When kernel panic occurs, we can get this log buffer from
> crashdump file by kdump, and reconstruct the flow that led to the panic.
Good to see this work going forward!
> Takao Indoh
On 29-07-15, 03:38, Rafael J. Wysocki wrote:
> The rule is supposed to be "all of the present CPUs which do not own
> a policy should point to one, unless it doesn't exist". The right
> approach is then to create links from them to a policy object as soon
> as we create one for them. Waiting for
Hi all,
Am 29.07.2015 um 05:13 schrieb Rob Herring :
> On Tue, Jul 28, 2015 at 3:23 PM, Belisko Marek
> wrote:
>> Hi Dmitry,
>>
>> On Thu, Jul 23, 2015 at 10:53 PM, Dmitry Torokhov
>> wrote:
>>> On Thu, Jul 23, 2015 at 10:38:34PM +0200, Marek Belisko wrote:
Fix following:
[8.862
Hi,
> From: linux-kernel-ow...@vger.kernel.org
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> (2015/07/27 23:34), Michal Hocko wrote:
> > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> > The check could be also relaxed a bit and nmi_panic would
> > return onl
On 2015/07/29 14:44, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> Hi all,
>>
>> This patch creates log buffer for Intel PT and enable logging at boot
>> time. When kernel panic occurs, we can get this log buffer from
>> crashdump file by kdump, and reconstruct the flow that led to the pan
When use rtc-pl031 for suspend test on Hisilicon's SoC Hi6220, Usually
the data register (DR) will read back as value zero. So the suspend
test code will set the match register (MR) for 10 seconds' timeout; But
there have chance later will read back some random values from DR
register; So finally m
Takao Indoh writes:
> This patch provides Intel PT logging feature. When system boots with a
> parameter "intel_pt_log", log buffers for Intel PT are allocated and
> logging starts, then processor flow information is written in the log
> buffer by hardware like flight recorder. This is very helpf
The module name of the Realtek USB Memstick Card Interface Driver should be
rtsx_usb_ms, instead of rts5139_ms.
Signed-off-by: AceLan Kao
---
drivers/memstick/host/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kc
The email address missed character ">", so add it.
Signed-off-by: Leo Yan
---
drivers/rtc/rtc-pl031.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-pl031.c b/drivers/rtc/rtc-pl031.c
index 99181fff..41dcb7d 100644
--- a/drivers/rtc/rtc-pl031.c
+++ b/drivers/r
On 28 July 2015 at 17:31, Rob Herring wrote:
> On Tue, Jul 28, 2015 at 8:54 AM, Tomeu Vizoso
> wrote:
>> On 28 July 2015 at 15:39, Rob Herring wrote:
>>> On Tue, Jul 28, 2015 at 8:19 AM, Tomeu Vizoso
>>> wrote:
From an arbitrary node in the tree, find the enclosing node that
correspon
Hi Sören,
On Tue, Jul 28, 2015 at 3:53 PM, Sören Brinkmann
wrote:
> On Mon, 2015-07-27 at 09:52PM -0700, Moritz Fischer wrote:
>> Hi Sören,
>>
>> thanks for your feedback.
>>
>> On Mon, Jul 27, 2015 at 7:58 PM, Sören Brinkmann
>> wrote:
>> > Hi Moritz,
>> >
>> > On Fri, 2015-07-24 at 05:21PM -07
Hi,
Description
===
The Maxim 77843 haptic driver differs from 77693 by:
1. Setting the bias.
2. Different configuration register.
3. Not enabling the low-sys DAC.
4. Using same regmap for PMIC and haptic blocks.
The patchset merges max77843 driver into the max77693.
Dependencies
=
The max77693 haptic driver supports Maxim 77843 device so remove the
max77843 driver.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/Kconfig | 12 --
drivers/input/misc/Makefile | 1 -
drivers/input/misc/max77843-haptic.c | 359 ---
The Maxim 77843 haptic driver differs from 77693 by:
1. Setting the bias.
2. Different configuration register.
3. Not enabling the low-sys DAC.
4. Using same regmap for PMIC and haptic blocks.
Incorporate all differences into max77693 haptic driver so both devices
can be supported.
Signed-off-by:
Prepare the driver for supporting two devices: Maxim 77693 and 77843:
1. Add table of device ids and store current device type for later
usage.
2. Differentiate the haptic device configuration.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/max77693-haptic.c | 41 ++
On Mon, 2015-07-27 at 14:23 +0100, Robin Murphy wrote:
> On 16/07/15 10:04, Yong Wu wrote:
> > This patch adds support for mediatek m4u (MultiMedia Memory Management
> > Unit).
> >
> > Signed-off-by: Yong Wu
> [...]
> > +static void mtk_iommu_flush_pgtable(void *ptr, size_t size, void *cookie)
> >
Storing a predefined PWM divisor in state container structure is
meaningless. The field, after initialization, is only read so this only
obfuscates the code. Remove the field and use directly enum value.
Signed-off-by: Krzysztof Kozlowski
---
drivers/input/misc/max77693-haptic.c | 4 +---
1 file
On 07/29/2015 02:33 AM, David Rientjes wrote:
> On Fri, 24 Jul 2015, Vlastimil Babka wrote:
>
>> > Two issues I want to bring up:
>> >
>> > (1) do non-thp configs benefit from periodic compaction?
>> >
>> > In my experience, no, but perhaps there are other use cases where
>> > this
On 07/23/2015 09:05 PM, R, Vignesh wrote:
>
>
> On 7/16/2015 9:01 PM, R, Vignesh wrote:
>> Hi,
>>
>> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
>>> Hi,
>>>
>>> some comments.
>>>
>>> On Wed, 3 Jun 2015, Vignesh R wrote:
>>>
Add hwmod entries for the PWMSS on DRA7.
Set l4_root_c
On Tue, Jul 28, 2015 at 03:21:01PM +0200, Peter Zijlstra wrote:
> There are various problems and short-comings with the current
> static_key interface:
>
> - static_key_{true,false}() read like a branch depending on the key
>value, instead of the actual likely/unlikely branch depending on
>
Hi Matt,
Le Monday 27 July 2015 à 14:38 +0100, Matt Fleming a écrit :
> From: Matt Fleming
>
> The revision of the watchdog hardware in Sunrisepoint necessitates a new
> "version" inside the TCO watchdog driver because some of the register
> layouts have changed.
>
> Cc: Wim Van Sebroeck
> Sig
Le Tuesday 28 July 2015 à 10:46 +0100, Lee Jones a écrit :
> On Mon, 27 Jul 2015, Matt Fleming wrote:
> > + strcpy(pdata->name, info->name);
>
> strncpy() is safer.
And strlcpy() is even better.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linu
On Tue, Jul 28, 2015 at 03:20:55PM +0200, Peter Zijlstra wrote:
> Hi all,
>
> After yet another bug because of the weirdness of the static key interface,
> here an attempt at providing a better one.
>
> This series is tested on x86_64 (by me) and s390x (heiko).
Works nice. You may include the s3
On Tue, 28 Jul 2015 23:06:15 +0200,
Andrew Morton wrote:
>
> On Tue, 28 Jul 2015 00:03:01 +0300 Alexey Dobriyan
> wrote:
>
> > Convert away from deprecated simple_strto*() interfaces to
> > parse_integer() and kstrto*().
>
> The patch does a lot more than this! It also adds lots of handling o
On Mon, Jul 27, 2015 at 04:26:03PM -0700, Dan Williams wrote:
> Oh, because all we have at this point is ioremap_cache() which
> silently falls back. It's not until the introduction of
> arch_memremp() where we update the arch code to break that behavior.
Ok, makes sense. Might be worth to docum
Add REF2USB_TX clock support into MT8173 APMIXEDSYS. This clock
is needed by USB 3.0.
Signed-off-by: James Liao
---
drivers/clk/mediatek/Makefile | 2 +-
drivers/clk/mediatek/clk-apmixed.c | 107 +
drivers/clk/mediatek/clk-mt8173.c | 47 ++
The dpi_ck clock can be removed because it not actually used
in topckgen and subsystems.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 1 -
include/dt-bindings/clock/mt8173-clk.h | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/clk/mediatek/clk-mt8173.c
b/dr
Most multimedia subsystem clocks will be accessed by multiple
drivers, so it's a better way to manage these clocks in CCF.
This patch adds clock support for MM, IMG, VDEC, VENC and VENC_LT
subsystems.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 267
On Mon, Jul 20, 2015 at 05:27:21PM +0530, Sudip Mukherjee wrote:
> parport_find_base() will implicitly do parport_get_port() which
> increases the refcount. Then parport_register_device() will again
> increment the refcount. But while unloading the module we are only
> doing parport_unregister_devi
This patch fixes the following checkpatch.pl warning:
WARNING: braces {} are not necessary for single statement blocks
Signed-off-by: Shraddha Barke
---
drivers/staging/wilc1000/coreconfigurator.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/core
Remove the dependency from clk_null, and give all root clocks a
typical rate, include clkph_mck_o, usb_syspll_125m and hdmitx_dig_cts.
dpi_ck was removed due to no clock reference to it.
Replace parent clock of infra_cpum with cpum_ck, which is an external
clock and can be defined in the device t
This patch adds device nodes providing subsystem clocks on MT8173,
includes mmsys, imgsys, vdecsys, vencsys and vencltsys.
Signed-off-by: James Liao
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/
This adds the binding documentation for the mmsys, imgsys, vdecsys,
vencsys and vencltsys controllers found on Mediatek SoCs.
Signed-off-by: James Liao
---
.../bindings/arm/mediatek/mediatek,imgsys.txt | 22 ++
.../bindings/arm/mediatek/mediatek,mmsys.txt | 22
2015-07-29 15:31 GMT+09:00 Krzysztof Kozlowski :
> The max77693 haptic driver supports Maxim 77843 device so remove the
> max77843 driver.
>
> Signed-off-by: Krzysztof Kozlowski
Crap, wrong signed-off-by. I'll respin.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsub
Remove unused header files from MT8173, and remove unused
keywords from function declaration.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mt8173.c | 2 --
drivers/clk/mediatek/clk-mtk.h| 4 ++--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/mediatek/cl
On Mon, 27 Jul 2015 23:03:01 +0200,
Alexey Dobriyan wrote:
>
> Convert away from deprecated simple_strto*() interfaces to
> parse_integer() and kstrto*().
>
> Signed-off-by: Alexey Dobriyan
The error handling looks good to me. In addition to Andrew's
suggestion and the removal of word terminat
From: Sascha Hauer
On the MT8173 the clocks are provided by different units. To enable
the critical clocks we must be sure that all parent clocks are already
registered, otherwise the parents of the critical clocks end up being
unused and get disabled later.
On MT8173, for example, it is the CLK
Add __init for clock registration functions, and add __initdata for
mtk_gate_regs initial structures.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-gate.c | 2 +-
drivers/clk/mediatek/clk-mt8173.c | 6 +++---
drivers/clk/mediatek/clk-mtk.c| 13 +++--
3 files changed, 11
This patchset is based on 4.2-rc1 and [1], and contains minor fixes and
subsystem clocks support for Mediatek MT8173.
The previous reviews can be found in [2]. The most different from previous
patchset are adding separated patches for minor coding fixes, and refining
USB clock implementation by re
This patch adds fixed clocks support by using CCF fixed-rate
clock implementation.
Signed-off-by: James Liao
---
drivers/clk/mediatek/clk-mtk.c | 23 +++
drivers/clk/mediatek/clk-mtk.h | 17 +
2 files changed, 40 insertions(+)
diff --git a/drivers/clk/mediate
Le 28/07/2015 07:03, Moritz Fischer a écrit :
> Hi Michal,
>
> I agree we need to be careful with changing the bindings.
>
> On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote:
>> Hi Moritz,
>>
>> On 07/25/2015 02:21 AM, Moritz Fischer wrote:
>>> Signed-off-by: Moritz Fischer
>>> ---
>>> arc
From: Pan Xinhui
Userspace at most time do cpufreq tests very much inconveniently.
Currently they have to echo min and max cpu freq separately like below:
echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 224 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
Add
Hi Wim,
Atmel Watchdog Timer has a new feature from SAMA5D4, the Watchdog Timer Mode
Register can be written more than once, so the driver can enable/disable
the watchdog timer hardware and set the watchdog timer hardware timeout.
The patch set is to add new feature.
Wenyou Yang (2):
drivers:
In the datasheet, the new feature is describled as
"WDT_MR can be written until a LOCKMR command is issued in WDT_CR".
That is to say, as long as the bootstrap and u-boot don't issue a LOCKMR
command, WDT_MR can be written in kernel.
So the driver can enable/disable the watchdog timer hardware,
se
On Fri, Jul 24, 2015 at 03:41:27PM -0700, Kees Cook wrote:
> Since the API for jent_panic() does not include format string parameters,
> adjust the call to panic() to use a literal string to avoid any future
> callers from leaking format strings into the panic message.
>
> Signed-off-by: Kees Cook
Add a new compatible "atmel,sama5d4-wdt" for SAMA5D4,
which suports the new feature, the WDT_MR register can be written more once.
Signed-off-by: Wenyou Yang
---
.../devicetree/bindings/watchdog/atmel-wdt.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documenta
On 28-07-15, 15:02, Pan Xinhui wrote:
> From: Pan Xinhui
>
> Userspace at most time do cpufreq tests very much inconveniently.
> Currently they have to echo min and max cpu freq separately like below:
> echo 48 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
> echo 224 > /sys/dev
On 07/28/2015 12:00 AM, Wenyou Yang wrote:
In the datasheet, the new feature is describled as
"WDT_MR can be written until a LOCKMR command is issued in WDT_CR".
That is to say, as long as the bootstrap and u-boot don't issue a LOCKMR
command, WDT_MR can be written in kernel.
So the driver can e
The semantic patch used to make this change is :
@@
@@
for (...;...;...) {
...
if (...) {
...
- continue;
}
}
Signed-off-by: Shraddha Barke
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c
b/drivers/i
Hi Peter,
On Fri, Jul 17, 2015 at 09:34:31AM -0400, Peter Hurley wrote:
> On 07/16/2015 04:29 AM, Joerg Roedel wrote:
> > From: Joerg Roedel
> >
> > The XR17V35X UART needs the ECB bit set in its XR_EFR
> > register to enable access to IER [7:5], ISR [5:4], FCR[5:4],
> > MCR[7:5], and MSR [7:0].
On Tue, Jul 28, 2015 at 12:30 AM, Dmitry Torokhov
wrote:
> On Mon, Jul 20, 2015 at 03:05:44PM +0300, Robert Dolca wrote:
>> Hi Dmitry,
>>
>> On Mon, Jul 20, 2015 at 9:51 AM, Dmitry Torokhov
>> wrote:
>> > On Fri, Jul 10, 2015 at 06:11:04PM +0300, Robert Dolca wrote:
>> > > This driver adds suppor
On Tue, 28 Jul 2015, Shraddha Barke wrote:
> The semantic patch used to make this change is :
>
> @@
> @@
> for (...;...;...) {
> ...
> if (...) {
> ...
> - continue;
> }
> }
>
> Signed-off-by: Shraddha Barke
> ---
> drivers/isdn/hardware/mISDN/hfcsusb.c | 1 -
> 1 file changed, 1
Le 20/07/2015 18:42, Sebastian Reichel a écrit :
> Hi,
>
> On Mon, Jul 20, 2015 at 05:32:05PM +0800, Josh Wu wrote:
>> This patch introduces a new compatible string: "atmel,sama5d3-rstc" and
>> new reset function for sama5d3 and later chips.
>>
>> As in sama5d3 or later chips, we don't have to shu
Le 22/06/2015 09:45, Alexandre Belloni a écrit :
> The ADC pinctrl is board specific, move it to the board device trees.
>
> Signed-off-by: Alexandre Belloni
To the series:
Acked-by: Nicolas Ferre
> ---
> arch/arm/boot/dts/at91-sama5d4_xplained.dts | 9 +
> arch/arm/boot/dts/at91-sama
On Tue, 28 Jul 2015, Viresh Kumar wrote:
> Cc'ing few people (whom I cc'd last time as well :)).
>
> On 27-07-15, 16:20, Lee Jones wrote:
> > These OPPs are used in ST's CPUFreq implementation.
> >
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - None, new patch
> >
> > Documen
The device reset is necessary if the hw becomes abnormal and stops
transmitting packets.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index a6caa
Although the driver works normally, we find the device may get all 0xff data
when
tranmitting packets on certain platforms. It would break the device and no
packet
could be transmitted. The reset is necessary to recover the hw for this
situation.
Hayes Wang (2):
r8152: add pre_reset and post_
Add rtl8152_pre_reset() and rtl8152_post_reset() which are used when
calling usb_reset_device(). The two functions could reduce the time
of reset when calling usb_reset_device() after probe().
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 68
Le 16/06/2015 12:08, Josh Wu a écrit :
> Add Atmel-isi and ov2640 driver in defconfig
>
> Signed-off-by: Josh Wu
> ---
>
> Changes in v2: None
>
> arch/arm/configs/at91_dt_defconfig | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/configs/at91_dt_defconfig
> b/arch/arm
This commit removes the cap on the DualShock 4 controller reporting
rate when connected using Bluetooth. The previous value of '0xB0'
capped the rate to only 20.83 Hz which many userspace utilities
mistook as a sign of a bad signal. Since a 'B' and an '8' can look
similar it's possible that someon
On Tue, 28 Jul 2015, Viresh Kumar wrote:
> On 27-07-15, 16:20, Lee Jones wrote:
> > Cc: devicet...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> >
> > Changelog:
> > - Using OPP-v2
> > - Moved (and linked) a bunch of documentation to ../power/
> >
> > .../devicetree/bindings/cpufreq
On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
> On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > From: S Twiss
> > >
> > > Add device tree bindings for the DA9062 OnKey driver component
> > >
> > > Signed-off-by: S
On 28 July 2015 06:40, Dmitry Torokhov wrote:
> Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for
> DA9062 OnKey
>
> On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > On Thu, Jul 23, 2015 at 05:17:41PM +0100, S Twiss wrote:
> > > From: S Twiss
> > >
Hi David,
On 07/28/2015 05:16 AM, Davidlohr Bueso wrote:
> On Mon, 2015-07-27 at 13:10 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi David,
>>
>> On 03/31/2015 04:45 PM, Davidlohr Bueso wrote:
>>> On Sat, 2015-03-28 at 12:47 +0100, Peter Zijlstra wrote:
>>>
The condition is represent
On 28 July 2015 08:43 Lee Jones wrote:
> To: Dmitry Torokhov
> Subject: Re: [PATCH V3 3/3] devicetree: da9062: Add device tree bindings for
> DA9062 OnKey
>
> On Mon, 27 Jul 2015, Dmitry Torokhov wrote:
>
> > On Mon, Jul 27, 2015 at 03:43:00PM -0700, Dmitry Torokhov wrote:
> > > On Thu, Jul 23
On 07/28/2015 08:59 AM, Nicolas Ferre wrote:
> Le 28/07/2015 07:03, Moritz Fischer a écrit :
>> Hi Michal,
>>
>> I agree we need to be careful with changing the bindings.
>>
>> On Sun, Jul 26, 2015 at 11:56 PM, Michal Simek wrote:
>>> Hi Moritz,
>>>
>>> On 07/25/2015 02:21 AM, Moritz Fischer wrote
On 28-07-15, 08:34, Lee Jones wrote:
> I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly
There are other properties in op.txt like turbo, opp-suspend, latency,
etc.. which can be useful for your platform to. Its not used for now
is a different thing.
> it would be annoying to
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> From: Mika Westerberg
>
> Typically when a device is created the bus core it belongs to (for example
> PCI) does not know if the device supports things like latency tolerance.
> This is left to the driver that binds to the device in question. However
On Tue, 28 Jul 2015, Rafael J. Wysocki wrote:
> On Monday, July 27, 2015 10:29:34 PM Lee Jones wrote:
> > On Mon, 27 Jul 2015, Lee Jones wrote:
> >
> > > On Mon, 27 Jul 2015, Rafael J. Wysocki wrote:
> > >
> > > > On Monday, July 27, 2015 05:24:13 PM Lee Jones wrote:
> > > > > On Mon, 27 Jul 201
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> From: "Rafael J. Wysocki"
>
> If the parent is still suspended when driver probe is
> attempted, the result may be failure.
>
> For example, if the parent is a PCI MFD device that has been
> suspended when we try to probe our device, any register
>
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> The new function device_for_each_child_reverse() is helpful to traverse the
> registered devices in a reversed order, e.g. in the case when an operation on
> each device should be done first on the last added device, then on one before
> last and so on
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> From: Mika Westerberg
>
> Some devices, like MFD subdevices, share a single ACPI companion device so
> that they are able to access their resources and children. However,
> currently all these subdevices are attached to the ACPI power domain and
> th
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> klist_prev() gets the previous element in the list. It is useful to traverse
> through the list in reverse order, for example, to provide LIFO (last in first
> out) variant of access.
>
> Signed-off-by: Andy Shevchenko
> Acked-by: Greg Kroah-Hartman
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> The new coming Intel platforms such as Skylake will contain Sunrisepoint PCH.
> The main difference to the previous platforms is that the LPSS devices are
> compound devices where usually main (SPI, HSUART, or I2C) and DMA IPs are
> present.
>
> This
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> The newly introduced device_for_each_child_reverse() would be used when MFD
> core removes the device.
>
> After this patch applied the devices will be removed in a reversed order. This
> behaviour is useful when devices have implicit dependency on or
From: David Dueck
Not all gpio banks are necessarily enabled, in the current code this can
lead to null pointer dereferences.
[ 51.13] Unable to handle kernel NULL pointer dereference at virtual
address 0058
[ 51.13] pgd = dee04000
[ 51.13] [0058] *pgd=3f66d831, *pte=0
On Mon, 27 Jul 2015, Andy Shevchenko wrote:
> Intel integrated DMA (iDMA) 64-bit is a specific IP that is used as a part of
> LPSS devices such as HSUART or SPI. The iDMA IP is attached for private
> usage on each host controller independently.
>
> While it has similarities with Synopsys DesignWa
The kernel's NMI watchdog has nothing to do with the watchdog
subsystem. Its header declarations are in linux/nmi.h, not in
linux/watchdog.h.
Cc: Stephane Eranian
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Signed-off-by: Guenter Roeck
---
arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
include
Cc'ing Rob as well..
On 28-07-15, 08:41, Lee Jones wrote:
> I have two issues with that. Firstly, although the driver uses the
> OPP API (it also uses the Regulator and Clock API too), it is
> fundamentally a CPUFreq driver, so I think it should have a CPUFreq
> DT entry. Secondly, if someone do
FAO Vinod,
On Tue, 28 Jul 2015, Lee Jones wrote:
> On Mon, 27 Jul 2015, Andy Shevchenko wrote:
>
> > Intel integrated DMA (iDMA) 64-bit is a specific IP that is used as a part
> > of
> > LPSS devices such as HSUART or SPI. The iDMA IP is attached for private
> > usage on each host controller ind
There is an API to do the same operation on kernel side than on userland.
You can get an dmabuf handle, select the allocator if required, and
secure it on kernel side.
Your question makes me realize that I have forget to add an
EXPORT_SYMBOL for smaf_create_handle function, I will fix that.
Benja
On Tue, 21 Jul 2015, Kanaka Juvva wrote:
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> index 1880761..dc1ce58 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_cqm.c
> @@ -12,10 +12,20
On Tue 28-07-15 11:02:11, Hidehiro Kawai wrote:
[...]
> > Something like
> [...]
> > +void nmi_panic(const char *fmt, ...)
>
> Since we can't directly pass variable arguments to a subroutine,
Sure, I was just too lazy to finish this as it was just an illustration
of the idea.
> we have to use a
Le 28/07/2015 09:48, Ludovic Desroches a écrit :
> From: David Dueck
>
> Not all gpio banks are necessarily enabled, in the current code this can
> lead to null pointer dereferences.
>
> [ 51.13] Unable to handle kernel NULL pointer dereference at virtual
> address 0058
> [ 51.13000
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Search and conversion was done with coccinelle.
>
> Reported-by: Russell King
> Signed-off-by:
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Search and conversion was done with coccinelle:
>
> Reported-by: Russell King
> Signed-off-by:
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Search and conversion was done with coccinelle:
>
> Reported-by: Russell King
> Signed-off-by:
Am Freitag, den 24.07.2015, 17:21 -0700 schrieb Moritz Fischer:
> Signed-off-by: Moritz Fischer
> ---
> Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
> 1 file changed, 13 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Reported-by: Russell King
> Signed-off-by: Thomas Gleixner
> Cc: Julia Lawall
> Cc: Samuel Or
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> irq is incremented for no value in the for loop. Remove it.
>
> Search and update was done with coccinelle and the invaluable help of
> Julia Lawall.
>
> Signed-off-by: Thomas Gleixner
> Cc: Julia Lawall
> Cc: Jiang Liu
> Cc: Samuel Ortiz
> Cc: L
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> It's pretty silly to do
>
> irq_data *d = irq_get_irq_data(irq_data->irq);
>
> because that results in d = irq_data, but goes through a lookup of the
> irq_data. Use irq_data directly.
>
> Signed-off-by: Thomas Gleixner
> Cc: Lee Jones
> Cc:
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> From: Jiang Liu
>
> Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
> already have a pointer to corresponding irq_desc.
>
> Do the same change to avoid the pattern "irq_get_chip_data(data->irq)".
>
> Signed-off-by: Jiang Liu
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Search and conversion was done with coccinelle.
>
> Reported-by: Russell King
> Signed-off-by:
On 07/24/2015 06:15 AM, Michal Simek wrote:
> + Kedar
>
> On 07/23/2015 11:13 PM, Andrea Scian wrote:
>> Simply resetting the peripheral on RX FIFO overflow in not enough,
>> because we also need to re-initialize the whole device.
>> Also always enable RX FIFO overflow interrupt otherwise we may h
On 27/07/15 21:32, Andy Gross wrote:
On Mon, Jul 27, 2015 at 02:50:12PM +0100, Srinivas Kandagatla wrote:
sdcc3: sdcc@1218 {
status = "okay";
+ vmmc-supply = <&pm8921_l6>;
Some userspace code occasionally has a need to reference the syscall
numbers for different-but-compatible architectures, so explicitly
export the generated files that contain the __NR_ia32_ and
__NR_x32_ constants.
Also, add a new generated unistd_64_amd64.h file, holding amd64
system call numbers
On Mon, 13 Jul 2015, Thomas Gleixner wrote:
> Chained irq handlers usually set up handler data as well. We now have
> a function to set both under irq_desc->lock. Replace the two calls
> with one.
>
> Search and conversion was done with coccinelle.
>
> Reported-by: Russell King
> Signed-off-by:
A while ago I was trying to build a seccomp-bpf filter program that would
survive a change of x86 architecture. This was complicated for all sorts of
reasons, but one of the problems was that the different syscall numbers aren't
all available at the same time -- hence this patch.
Naming-wise, And
501 - 600 of 1106 matches
Mail list logo