On Tue, Apr 21, 2015 at 09:41:22AM -0700, Linus Torvalds wrote:
> On Tue, Apr 21, 2015 at 3:10 AM, Greg KH wrote:
> >
> > TTY/Serial patches for 4.1-rc1
> >
> > Here's the big tty/serial driver update for 4.1-rc1.
>
> This causes Kconfig annoyances:
>
> High Speed UART DMA support (HSU_DMA) [N
* Andy Lutomirski wrote:
> Hi all-
>
> On x86_64, we use IST for #BP and #DB. On x86_32, we don't.
>
> We started using IST for #BP in:
>
> b556b35e98ad [PATCH] x86_64: Move int 3 handler to debug stack and
> allow to increase it.
>
> and we started using IST for #DB even earlier in:
>
> 7
On Apr 22, 2015, at 2:31 AM, Christoph Hellwig wrote:
> On Wed, Apr 22, 2015 at 06:27:11AM +, Drokin, Oleg wrote:
>>> Nak on exporting symbols for broken staging code. Please get rid of
>>> the ioctls looking up path names in horrible ways in the lustre code.
>>
>> For a reference, is there
On Apr 22, 2015, at 2:31 AM, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2015 at 10:53:11PM -0700, Christoph Hellwig wrote:
>> Nak on exporting symbols for broken staging code. Please get rid of
>> the ioctls looking up path names in horrible ways in the lustre code.
>
> I agree with Christoph,
On 22/04/15 01:55, Sergey Senozhatsky wrote:
On (04/21/15 13:20), Marcin Jabrzyk wrote:
This config option doesn't provide any usage for zram.
agree, there is no pr_debug() in the current zram. so the change
looks good to me.
btw, same stands for zsmalloc (for the time being):
#ifdef C
As the --children option changes the output of perf report (and perf
top) it sometimes confuses users. Add more words and examples to help
understanding of the option's behavior - and how to disable it ;-).
Reviewed-by: Ingo Molnar
Cc: Taeung Song
Signed-off-by: Namhyung Kim
---
.../callchain
Linus,
while the description of commit cae2a173fe certainly makes sense, the
change itself ignores the __probe_kernel_write() code path, for which
the destination address is expected to be in kernel space but accesses
may still fault. I.e. the use of plain memset() causes
__probe_kernel_write() to
On Tue, Apr 21, 2015 at 10:53:11PM -0700, Christoph Hellwig wrote:
> Nak on exporting symbols for broken staging code. Please get rid of
> the ioctls looking up path names in horrible ways in the lustre code.
I agree with Christoph, we shouldn't be doing this. Let's fix lustre
"properly", which
On Wed, Apr 22, 2015 at 06:27:11AM +, Drokin, Oleg wrote:
> > Nak on exporting symbols for broken staging code. Please get rid of
> > the ioctls looking up path names in horrible ways in the lustre code.
>
> For a reference, is there a good example of a non-horrible way to look up a
> pathna
add CC: Tejun Heo
On 2015/4/21 18:15, Xishi Qiu wrote:
> Hot remove nodeXX, then hot add nodeXX. If BIOS report cpu first, it will call
> hotadd_new_pgdat(nid, 0), this will set pgdat->node_start_pfn to 0. As nodeXX
> exists at boot time, so pgdat->node_spanned_pages is the same as original.
>
add CC: Tejun Heo
On 2015/4/21 18:15, Xishi Qiu wrote:
> After hotadd_new_pgdat()->free_area_init_node(), pgdat's spanned/present are
> 0,
> and zone's spanned/present/managed are 0, so remove reset_node_managed_pages()
> and reset_node_managed_pages().
>
> Signed-off-by: Xishi Qiu
> ---
> m
On Apr 22, 2015, at 1:53 AM, Christoph Hellwig wrote:
> Nak on exporting symbols for broken staging code. Please get rid of
> the ioctls looking up path names in horrible ways in the lustre code.
For a reference, is there a good example of a non-horrible way to look up a
pathname?
Thanks.
Bye
On 21/04/15 17:50, Arnaldo Carvalho de Melo wrote:
> Em Thu, Apr 09, 2015 at 06:53:49PM +0300, Adrian Hunter escreveu:
>
>> It is assumed that AUX area decoding will synthesize events for
>> consumption by other tools. At this time, the main use of AUX area
>> tracing will be to capture instructi
This patch just remove duplicate definition of the macro
KASAN_FREE_PAGE in mm/kasan/kasan.h
Signed-off-by: Wang Long
---
mm/kasan/kasan.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 4986b0a..c242adf 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/ka
On Wed, Apr 15, 2015 at 10:26:34PM +0800, Dong Aisheng wrote:
> This patch series adds support in clock framework for clocks which operations
> requires its parent clock is on.
>
> Such clock type is initially met on Freescale i.MX7D platform that all clocks
> operations, including enable/disable,
This patch adds information of maintainers for APM X-Gene v1 PCIe
MSI/MSIX termination driver
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..a1b119b 100644
--- a/MAINTAINE
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block supports 2048 MSI termination ports coalesced into 16 physical HW IRQ
lines
and
X-Gene v1 PCIe MSI controller block provides PCIE MSI functionality for 5
X-Gene v1
PCIE ports
The driver for this binding is under 'drivers/pci/host/pci-xgene-msi.c'
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
.../devicetree/bindings/pci/xgene-pci-msi.txt | 68
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
Signed-off-by: Duc Dang
Signed-off-by: Tanmay Inamdar
---
arch/arm64/boot/dts/apm/apm-storm.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/a
This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
APM X-Gene v1 SoC supports its own implementation of MSI, which is not compliant
to GIC V2M specification for MSI Termination.
There is single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports. This
MSI
block su
Here's the usual "low-priority fixes that didn't make it into the last
few -rcs, with a twist: We had a fixes pull request that I didn't send
in time to get into 4.0, so we'll send some of them to Greg for -stable as
well.
Contents here is as usual not all that controversial:
- A handful of randc
Driver updates for v4.1. Some of these are for drivers/soc, where we find more
and more SoC-specific drivers these days. Some are for other driver subsystems
where we have received acks from the appropriate maintainers.
The larger parts of this branch are:
- MediaTek support for their PMIC wrappe
We were expecting to sit on this branch through most of the merge window since
the contents was merged into our tree late, but we ended up sitting on all of
our contents so it can go in with the rest.
The contents here is:
- A large branch of cleanups of the CM/PRM blocks on OMAP.
- A couple of p
As always, this tends to be one of our bigger branches. There are lots of
updates this release, but not that many jumps out as something that needs
more detailed coverage. Some of the highlights are:
- DTs for the new Annapurna Labs Alpine platform
- More graphics DT pieces falling into place on E
Our SoC branch usually contains expanded support for new SoCs and other core
platform code. In this case, that includes:
- Support for the new Annapurna Labs "Alpine" platform
- A rework greatly simplifying adding new platform support to the MCPM
subsystem (Multi-cluster power management)
- Cpuidl
The changes here belong to two main platforms:
- Atmel At91 is flipping the bit and going multiplatform. This includes some
cleanups and removal of code, and the final flip of config dependencies
- Shmobile has several platforms that are going multiplatform, but this
branch also contains a bunch
We keep collecting defconfig updates in a separate branch mostly to encourage
people to handle them separately and avoid conflicts between different topics.
Most of these are enablement of new drivers that have come in, or minor config
refreshes due to reorderings in Kconfig files, etc. I.e. mostl
We've got a fairly large cleanup branch this time. The bulk of this is removal
of non-DT platforms of several flavors:
- Atmel at91 platforms go full-DT, with removal of remaining board-file based
support
- OMAP removes legacy board files for three more platforms
- Removal of non-DT mach-msm, newe
Mostly DT updates for arm64, but also a couple of Kconfig additions.
Main contents:
- Qualcomm MSM8916/APQ8016
- Spreadtrum SC9836
- Xilinx ZynqMP
- Pincontrol entries for MediaTek MT8173
Conflicts: None
The following changes si
Hi Linus,
Again, we seem to be submitting quite late this window as well. Hopefully
it's not a continuing trend.
It's again a smallish merge window for us. The cleanup branch has a nice
negative delta of 16k lines, and as usual lately most of the new additions are
in DT contents for various platf
Hi Arnaldo,
On Tue, Apr 21, 2015 at 01:46:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Apr 22, 2015 at 01:16:29AM +0900, Namhyung Kim escreveu:
> > On Tue, Apr 21, 2015 at 12:41:33PM -0300, Arnaldo Carvalho de Melo wrote:
> > > > +++ b/tools/perf/Documentation/overhead-calculation.txt
> >
* Paul Gortmaker wrote:
> On Sat, Apr 18, 2015 at 8:53 PM, Len Brown wrote:
> > From: Len Brown
> >
>
> [...]
>
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index b7d31ca..d2a91da 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -884,6 +884,21 @@ config SCHED_M
On Tue, Apr 21, 2015 at 01:33:38PM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 21, 2015 at 09:30:55PM +0300, Jarkko Sakkinen wrote:
> > Enabled PPI interface to the character device sysfs directory accessible
> > both for 1.x and 2.0 devices.
> >
> > The ppi group is moved from the platform device
Hi Richard,
On 04/21/2015 09:33 PM, Richard Fitzgerald wrote:
> Signed-off-by: Richard Fitzgerald
> ---
> drivers/extcon/extcon-arizona.c | 33 ++---
> 1 files changed, 22 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/ext
Nak on exporting symbols for broken staging code. Please get rid of
the ioctls looking up path names in horrible ways in the lustre code.
--
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:/
On Mon, Apr 20, 2015 at 05:55:07PM +0200, Jan Kara wrote:
> > Is that a good idea to export these symbols, given that lustre may be
> > the only user?
> Yes, it is a good idea.
It was if lustre was in core code and these idiotic ioctls were something
we had to live with.
But lustre is in stagi
On 2015/4/21 17:09, Wangfei (William, Euler) wrote:
> 发件人: linuxarm-boun...@huawei.com [linuxarm-boun...@huawei.com] 代表 Xinwei Kong
> [kong.kongxin...@hisilicon.com]
> 发送时间: 2015年4月7日 18:40
> 收件人: rui.zhu...@intel.com; edubez...@gmail.com; mpor...@konsulko.com;
> jorge.ramirez-or...@linaro.org;
On 2015/04/21, 9:50 PM, "Boqun Feng" wrote:
>As pointed by Al Viro:
>
>https://lkml.org/lkml/2015/4/11/243
>
>There are bugs in ll_getname() because of wrong assumptions of returning
>values from strncpy_from_user(). Moreover, what ll_getname want to do is
>just to try copy the file name from use
On Tue, Apr 21, 2015 at 11:58:33AM -0700, Guenter Roeck wrote:
> On Tue, Apr 21, 2015 at 09:30:55PM +0300, Jarkko Sakkinen wrote:
> > Enabled PPI interface to the character device sysfs directory accessible
> > both for 1.x and 2.0 devices.
> >
> > The ppi group is moved from the platform device d
On Mon, Apr 20, 2015 at 10:41:38AM +0200, Michael Wang wrote:
> Introduce helper cap_ipoib() to help us check if the port of an
> IB device support IP over Infiniband.
I thought we were dropping this in favor of listing the actual
features the ULP required unconditionally? One of my messages had
On Sat, Apr 18, 2015 at 8:53 PM, Len Brown wrote:
> From: Len Brown
>
[...]
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index b7d31ca..d2a91da 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -884,6 +884,21 @@ config SCHED_MC
> making when dealing with multi-core
On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > Mike, do you think the time is right to just remove the iPath driver?
>
> With PAT now being default the driver effectively won't work
> with write-combining on modern kernels. Even if systems are old
> they likely had PAT supp
On Tue, Apr 21, 2015 at 09:52:14PM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2015 at 09:30:55PM +0300, Jarkko Sakkinen wrote:
> > -#define to_tpm_chip(n) container_of(n, struct tpm_chip, vendor)
> > +#define to_tpm_chip(n) container_of(dev, struct tpm_chip, dev)
>
> That doesn't look corr
Fixed a coding style issue
Signed-off-by: Jason Eastman
---
sound/last.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/last.c b/sound/last.c
index 43f2228..a47bbe0 100644
--- a/sound/last.c
+++ b/sound/last.c
@@ -25,7 +25,7 @@
static int __init alsa_sound_last_ini
Hi Paul,
many thanks for your review.
all the fixes will be on next patchset.
my comments are below.
At Mon, 20 Apr 2015 22:43:07 +0200,
Paul Bolle wrote:
>
> Some random observations while I'm still trying to wrap my head around
> all this (which might take quite some time).
>
> On Sun, 201
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
wrote:
> Hello!
>
> This patch series reduces the number of questions that RCU asks Kconfig
> users. After this series is applied, removing the RCU-related definitions
> from .config and running "make oldconfig" results in only the following:
>
>
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
wrote:
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 2e52502bfc95..a2f64e4fdb57 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -86,10 +86,10 @@ static void __init rcu_bootup_announce_oddn
On 2015.04.22 at 00:57 +0200, Hagen Paul Pfeifer wrote:
> We see ordinary "template" reuse of common driver code without renaming the
> copied static's. But compiled with CONFIG_OPTIMIZE_INLINING=y the inlining is
> not respected by gcc:
>
> atomic_inc: 544 duplicates
>rcu_read
On Tue, Apr 21, 2015 at 09:47:54PM +1000, Alexey Kardashevskiy wrote:
> On 04/21/2015 07:43 PM, David Gibson wrote:
> >On Mon, Apr 20, 2015 at 04:55:32PM +1000, Alexey Kardashevskiy wrote:
> >>On 04/20/2015 12:44 PM, David Gibson wrote:
> >>>On Fri, Apr 17, 2015 at 08:09:29PM +1000, Alexey Kardashe
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> RCU_FANOUT_LEAF's range and default values depend on the value of
> RCU_FANOUT, which at the time seemed like a cute way to save two lines
> of Kconfig code. However, adding a dependency from both of these
>
On Tue, Apr 21, 2015 at 3:55 PM, Paul E. McKenney
wrote:
> From: "Paul E. McKenney"
>
> This commit updates rcutortures configuration-fragment files to account
> for the move from the CONFIG_RCU_FANOUT_EXACT Kconfig parameter to the
> new rcutree.rcu_fanout_exact= boot parameter.
>
> Signed-off-b
From: Eric Dumazet
Mateusz Guzik reported :
Currently obtaining a new file descriptor results in locking fdtable
twice - once in order to reserve a slot and second time to fill it.
Holding the spinlock in __fd_install() is needed in case a resize is
done, or to prevent a resize.
Mateusz prov
As for extract, -a means all instances except the top one.
Use -t to get the top one too.
Signed-off-by: Howard Cochran
---
Documentation/trace-cmd-reset.1.txt | 57 +
Documentation/trace-cmd-stop.1.txt | 13 ++---
trace-record.c | 57
Add support for multiple -B instances, the same as
stop, reset, restart, and extract sub-commands.
-a operates on all instances except the top one
-t also includes the top instance
Signed-off-by: Howard Cochran
---
Documentation/trace-cmd-snapshot.1.txt | 16 +-
trace-cmd.c
Add -B option to trace-cmd extract so that it can extract listed
instances. As with start, stop, and reset, the top level instance is not
included when any -B are given. However, -t makes it also include the
top instance. As with other commands, if neither option is given, only
operate on the top i
This option will extract all instances that currently exist in the
system, including the top instance. This differs from the meaning of -a
for record and stream (enable all events), which would have no purpose
for extract. Such difference in meaning already exists for -s, so this
seemed reasonable.
As for stop, restart, reset, extract, -a means show status of
all buffer instances except the top one. Use -t to get the top
one too.
Also added documentation for the existing -B and -t options.
Signed-off-by: Howard Cochran
---
Documentation/trace-cmd-stat.1.txt | 19 +++
trace
NOTE: The previous two versions of this patch set were distributed off-list.
v3 changes:
* Improved clarification of options in documentation of
trace-cmd reset and added examples.
v2 changes:
* Rebased this patch series on Steve's simplification of
first_instance logic.
Impr
From: Fenghua Yu
When enumerating xstate offsets and sizes from cpuid (eax=0x0d, ecx>=2),
it's possible that state m is not implemented while state n (n>m)
is implemented. So enumeration shouldn't stop at state m.
There is no platform configured like above yet. But this could be a problem
in the
From: Fenghua Yu
If "xsaves" is enabled, kernel always uses compact format of xsave area.
But user space still uses standard format of xsave area. Thus, xstate size
in kernel's xsave area is smaller than xstate size in user's xsave area.
xstate in signal frame should be in standard format for use
From: Fenghua Yu
User space uses standard format xsave area. fpstate in signal frame should
have standard format size.
To explicitly distinguish between xstate size in kernel space and the one
in user space, we rename xstate_size to kernel_xstate_size. This patch is
not fixing a bug. It just mak
From: Fenghua Yu
The structure of xsave_struct is non-architectural. Some xstates could be
disabled and leave some holes in the xsave area. In compact format,
offsets of xstates in the xsave area are decided during booting time.
So the fields in xsave_struct are not static and fixed during compi
From: Fenghua Yu
This patchset is supposed to fix some xsave/xsaves related issues.
The patch 1/4 fixes an xstate offsets and sizes enumeration issue. During
enumerating offsets and sizes starting from 2 to the last enabled feature,
if one xstate's size is 0, current code thinks there is no othe
On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote:
> On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley
> wrote:
> > On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
> >> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
> >> wrote:
> >> > Andy, just on the misc device idea, what abo
Hi all,
Please do not add any v4.2 material to your linux-next included trees
until after v4.1-rc1 is released.
Changes since 20150421:
*crickets*
Non-merge commits (relative to Linus' tree): 2194
2085 files changed, 109693 insertions(+), 55971 dele
On Tue, 04/21 19:58, James Bottomley wrote:
> On Tue, 2015-03-24 at 18:16 +0800, Fam Zheng wrote:
> > If the disk can't read capacity, we should return an error.
>
> I'm not sure I buy this: you need to justify why.
>
> For instance removable media return an error in revalidate that causes
> the
(resending in plain text)
(please CC me on replies, I am not on LKML)
Hi,
I have a new Mac Mini (MacMini7,1). This model supports hotplugging of
Thunderbolt on Windows 8 and above. Unfortunately hotplug does not
seem to be working for me under Linux. I get the default behavior of
devices only wor
getname/putname in fs/namei.c is a well-implemented way to copy a file
name from userland, however other ways, such as directly calling
__getname() and strncpy_from_user(), may lack features(e.g. auditing and
reusing), introduce errors or at least reinvent wheels. Therefore for
places need a kernel
As pointed by Al Viro:
https://lkml.org/lkml/2015/4/11/243
There are bugs in ll_getname() because of wrong assumptions of returning
values from strncpy_from_user(). Moreover, what ll_getname want to do is
just to try copy the file name from userland. Since we already have
getname() for the same p
As Al Viro pointed out:
https://lkml.org/lkml/2015/4/11/243
There are bugs in ll_getname() because of wrong assumptions of returning
values from strncpy_from_user(). Moreover, what ll_getname want to do is
just to try copy the file name from userland. Since we already have
getname() for the same
Currently we're hiding mod->sig_ok under an ifdef in open code.
This patch adds a module_sig_ok accessor function and removes that
ifdef.
Cc: Rusty Russell
Signed-off-by: Herbert Xu
diff --git a/crypto/algapi.c b/crypto/algapi.c
index 8057c9f..c63836f 100644
--- a/crypto/algapi.c
+++ b/cryp
On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley
wrote:
> On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
>> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
>> wrote:
>> > Andy, just on the misc device idea, what about triggering the capsule
>> > update from close()? In theory close r
On Tue, Apr 21, 2015 at 7:32 PM, Linus Torvalds
wrote:
> On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
>>
>> If kdbus were a general purpose IPC tool
>
> .. but it's not ..
>
>> and if the libraries would
>> expose nice knobs like "set this flag if a
On Mon, 2015-04-20 at 21:48 +0100, Mark Brown wrote:
> On Mon, Apr 20, 2015 at 06:37:47AM +0200, Sascha Hauer wrote:
> > On Sat, Apr 18, 2015 at 06:34:07PM +0100, Mark Brown wrote:
> > > On Fri, Apr 10, 2015 at 04:14:07PM +0800, Koro Chen wrote:
>
> > > > +Each external interface (called "IO" in t
On Tue, Apr 21, 2015 at 2:28 AM, Paul Bolle wrote:
> On Mon, 2015-04-20 at 17:27 +0800, pi-cheng.chen wrote:
>> --- a/drivers/cpufreq/Kconfig.arm
>> +++ b/drivers/cpufreq/Kconfig.arm
>
>> +config ARM_MT8173_CPUFREQ
>> + bool "Mediatek MT8173 CPUFreq support"
>> + depends on ARCH_MEDIATEK &
On 04/21/2015 05:23 PM, Thomas Gleixner wrote:
> On Mon, 20 Apr 2015, Preeti U Murthy wrote:
>
>> On 04/15/2015 02:38 AM, Thomas Gleixner wrote:
Now that we have the active_bases field in sync we can use it for
>>
>> This sentence appears a bit ambiguous. I am guessing you are referring
>> to
On Tue, Apr 21, 2015 at 9:51 PM, Bernd Petrovitsch
wrote:
> Hi all!
>
> On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote:
> [...]
>> This has long been sort of the 'party line' and I've told many people
>> this on the dbus mailing list over the years (almost exactly what you
>> just said
Hi Josh,
Thanks for reviewing.
On Mon, Apr 20, 2015 at 10:17 PM, Josh Cartwright wrote:
> On Mon, Apr 20, 2015 at 05:27:26PM +0800, pi-cheng.chen wrote:
>> This patch implements MT8173 specific cpufreq driver with OPP table defined
>> in the driver code.
>>
>> Signed-off-by: pi-cheng.chen
>> --
On 04/21/2015 12:04 AM, Duc Dang wrote:
> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1
On 04/21/2015 12:04 AM, Duc Dang wrote:
> This patch set adds MSI/MSIX termination driver support for APM X-Gene v1 SoC.
> APM X-Gene v1 SoC supports its own implementation of MSI, which is not
> compliant
> to GIC V2M specification for MSI Termination.
>
> There is single MSI block in X-Gene v1
2015-04-21 8:41 GMT-07:00 Guenter Roeck :
> On Tue, Apr 21, 2015 at 01:45:35PM +0930, Rusty Russell wrote:
>> Aaro Koskinen writes:
>> > Hi,
>> >
>> > On Mon, Apr 20, 2015 at 12:40:28PM -0700, Guenter Roeck wrote:
>> >> the upstream kernel fails to build mips:nlm_xlp_defconfig,
>> >> mips:nlm_xlp_
1) ldc_alloc_exp_dring() can be called from softints, so use GFP_ATOMIC.
From Sowmini Varadhan.
2) Some minor warning/build fixups for the new iommu-common code on
certain archs and with certain debug options enabled. Also from
Sowmini Varadhan.
Please pull, thanks!
The following chan
Hi,
> -Original Message-
> From: Jonathan Corbet [mailto:cor...@lwn.net]
> Sent: Tuesday, April 21, 2015 8:14 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: Andrew Morton; Nathan Scott; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Jiri Kosina
> Subject: Re: [PATCH] Docs: proc: fix kernel
On Tue, 2015-03-24 at 18:16 +0800, Fam Zheng wrote:
> If the disk can't read capacity, we should return an error.
I'm not sure I buy this: you need to justify why.
For instance removable media return an error in revalidate that causes
the medium not present flag to be set ... do we really want to
Just a few fixes trickling in at this point.
1) If we see an attached socket on an skb in the ipv4 forwarding
path, bail. This can happen due to races with FIB rule addition,
and deletion, and we should just drop such frames. From Sebastian
Pöhn.
2) pppoe receive should only accept pa
On Tue, Apr 21, 2015 at 11:36:40PM +, Liran Liss wrote:
> Hi Michael,
>
> The spirit of this patch-set is great, but I think that we need to clarify
> some concepts.
> Since this will affect the whole patch-set, I am laying out my concerns here
> instead.
>
> A suggestion for the resulting
Hi,
On Mon, Apr 20, 2015 at 05:55:07PM +0200, Jan Kara wrote:
> On Fri 17-04-15 20:35:30, Boqun Feng wrote:
> > Hi Al,
> >
> >
> > I'm trying to clean that part of code you mentioned, and I found I have
> > to export the symbols 'getname' and 'putname' as follow to replace that
> > __getname() c
On Tue, Apr 21, 2015 at 6:54 PM, Andy Lutomirski wrote:
>
> If kdbus were a general purpose IPC tool
.. but it's not ..
> and if the libraries would
> expose nice knobs like "set this flag if and only if you want to
> assert CAP_WHATEVER to the server", then
Steven Rostedt wrote on 04/21/15 17:44:
[ Added a bunch of people that use perf ;-) ]
Thanks. I hope they can help me get the patch accepted.
[snip]
+/*
+ * Allow modules to register additional trace routines
+ */
+EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_entry);
+EXPORT_TRACEPOINT_SYMBOL_
On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote:
> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
> wrote:
> > Andy, just on the misc device idea, what about triggering the capsule
> > update from close()? In theory close returns an error code (not sure if
> > most tools actually check
On Tue, Apr 21, 2015 at 10:34:01AM +0300, Roger Quadros wrote:
> On 21/04/15 09:04, Peter Chen wrote:
> >
> >>
> >> On 20/04/15 06:05, Peter Chen wrote:
> >>> On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote:
> This is an attempt to centralize OTG/Dual-role functionality in the
On 04/21/2015 08:09 PM, Alexandre Belloni wrote:
> On 21/04/2015 at 18:58:43 -0500, Nishanth Menon wrote :
>>>
>>> Consider the following use case: a platform is setting the RTC alarm
>>> before going to suspend to ram. Before your patch, it may be woken up
>> ^^ precisely what I am trying to solve
On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley
wrote:
> Andy, just on the misc device idea, what about triggering the capsule
> update from close()? In theory close returns an error code (not sure if
> most tools actually check this, though). That means we can do the write
> in chunks but pass
On Tue, Apr 21, 2015 at 6:30 PM, Linus Torvalds
wrote:
> On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
> wrote:
>> - Access to the capability bits is guarded with PTRACE_MAY_READ
>> kdbus does not honor that and thus leaks information.
>
> Now, this is likely not a real problem.
>
> Yes, w
Hi all!
On Die, 2015-04-21 at 09:37 -0400, Havoc Pennington wrote:
[...]
> This has long been sort of the 'party line' and I've told many people
> this on the dbus mailing list over the years (almost exactly what you
> just said - that for performance-critical cases they should open a
> direct soc
On Tuesday, April 21, 2015 04:53:14 PM Jassi Brar wrote:
> On Tue, Apr 21, 2015 at 6:28 AM, Feng Kan wrote:
> >
> > Just want to ping this. I haven't gotten any response from mailbox
> > maintainer for this
> > patch or any of my other mailbox patches.
> >
> Sorry I had been busy and still need to
On 2015/4/22 0:21, Yasuaki Ishimatsu wrote:
>
> On Tue, 21 Apr 2015 18:15:31 +0800
> Xishi Qiu wrote:
>
>> Hot remove nodeXX, then hot add nodeXX. If BIOS report cpu first, it will
>> call
>> hotadd_new_pgdat(nid, 0), this will set pgdat->node_start_pfn to 0. As nodeXX
>> exists at boot time,
On Wednesday, April 15, 2015 07:01:06 PM Rafael J. Wysocki wrote:
> On Wednesday, April 15, 2015 05:36:42 PM Rafael J. Wysocki wrote:
> > On Apr 15, 2015 3:16 PM, "Rafael J. Wysocki" wrote:
> > >
> > > On Wed, Apr 15, 2015 at 2:55 PM, Bjorn Helgaas
> > wrote:
> > > > On Tue, Apr 14, 2015 at 8:03
On Tuesday, April 14, 2015 03:03:33 PM Rafael J. Wysocki wrote:
> On Tuesday, April 14, 2015 01:50:11 PM Rafael J. Wysocki wrote:
> > On Monday, April 13, 2015 07:04:14 PM Darren Hart wrote:
> > > On Sat, Apr 11, 2015 at 01:28:45AM +0200, Rafael Wysocki wrote:
> > > > From: Rafael J. Wysocki
> > >
On Tue, Apr 21, 2015 at 2:06 PM, Eric W. Biederman
wrote:
>
> - The userspace interface for capability bits has a version number that
> determines the quantity and the meaning of the bits, kdbus does not
> pass that number to userspace.
Well, realistically, we'll just have to freeze the versi
1 - 100 of 996 matches
Mail list logo
