On Tue, Feb 02, 2016 at 12:44:54PM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
> wrote:
> > But "struct pid *" in unix_skb_parms should be enough to get us to
> > corresponding "struct cred *" so we can decrement the correct counter during
> > skb
On Tuesday 02 February 2016 18:24:45 Zubair Lutfullah Kakakhel wrote:
> diff --git a/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
> b/Documentation/devicetree/bindings/mips/cavium/sata-uctl.txt
> new file mode 100644
> index 000..3bd3c2f
> --- /dev/null
> +++
On Tue, Feb 02, 2016 at 12:09:22PM -0600, Mario Limonciello wrote:
>
>
> On 02/02/2016 11:32 AM, Darren Hart wrote:
> > On Mon, Feb 01, 2016 at 08:28:50PM -0600, Mario Limonciello wrote:
> >> This allows configuration the system for wakeup with a controller.
> > Hrm, I'm happy to clean up
On Tue, Feb 02 2016, Eric Dumazet wrote:
> On Tue, 2016-02-02 at 00:08 +0100, Rasmus Villemoes wrote:
>
>> Thanks. (Is there a good way to tell gcc that avg*avg is actually a
>> 32x32->64 multiplication?)
>
> If avg is 32bit, compiler does that for you.
>
> u32 avg = ...
>
> u64 result =
On 02/02, Viresh Kumar wrote:
> On 01-02-16, 18:10, Stephen Boyd wrote:
>
> From: Viresh Kumar
> Date: Fri, 4 Sep 2015 12:28:39 +0530
> Subject: [PATCH] PM / OPP: Add dev_pm_opp_set_rate()
>
> This adds a routine, dev_pm_opp_set_rate(), responsible for configuring
> power-supply and clock
On Tue, Feb 2, 2016 at 12:32 PM, Hannes Frederic Sowa
wrote:
>
> Unfortunately we never transfer a scm_cookie via the skbs but merely use it
> to initialize unix_skb_parms structure in skb->cb and destroy it afterwards.
Ok, I obviously didn't check very closely.
> But "struct pid *" in
On Tue, Feb 02, 2016 at 02:02:30PM -0600, Bjorn Helgaas wrote:
> Remove some gpio and regulator #includes when they can be replaced by
> trivial forward struct declarations. Also move a linux/gpio/consumer.h
> #include from a header to the single .c files that uses it.
Please don't CC me on
On 02/02, Masahiro Yamada wrote:
> 2016-02-02 11:39 GMT+09:00 Stephen Boyd :
> >
> > Right, this patch moves the check to __clk_core_init(), and it
> > will print an error and then keep going (because we lost the goto
> > out part). Once we keep going in __clk_core_init() we'll call
> >
On Tue, Feb 02, 2016 at 08:54:34PM +0100, Heiko Carstens wrote:
> Hi Yury,
>
> On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> > See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> > "unsigned int" instead of u_long") would have been a candidate which
Hi Noam,
[auto build test ERROR on tip/irq/core]
[cannot apply to v4.5-rc2 next-20160202]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Noam-Camus/Adding-NPS400-drivers/20160202-213530
On Tue, Feb 02, 2016 at 09:32:56PM +0100, Hannes Frederic Sowa wrote:
> But "struct pid *" in unix_skb_parms should be enough to get us to
> corresponding "struct cred *" so we can decrement the correct counter
> during skb destruction.
>
> So:
>
> We increment current task's unix_inflight and
On Tue, 2 Feb 2016, Petr Mladek wrote:
> Note that TOC is not set only when the problematic functions are
> compiled with --mprofile-kernel. I still see the TOC stuff when
> compiling only with -pg.
I don't see how this wouldn't be a gcc bug.
No matter whether it's plain profiling call (-pg)
Em Tue, Feb 02, 2016 at 12:52:25PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Feb 02, 2016 at 12:24:19PM +0200, Adrian Hunter escreveu:
> > This patch does not fix the problem because the thread__zput() will still
> > segfault later if the error path is not taken.
> >
> > Sorry, I didn't
On 02.02.2016 20:29, Linus Torvalds wrote:
On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa
wrote:
Anyway, can someone provide a high-level description of what exactly
this patch is supposed to do? Which operation should be limited, who
should inflight FDs be accounted on, and which
I am announcing the release of the Linux 3.19.8-ckt14 kernel.
The updated 3.19.y-ckt tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.19.y
and can be browsed at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.19.y
The diff from v3.19.8-ckt13 is posted
Geliang Tang writes:
> Use list_for_each_entry*() instead of list_for_each*() to simplify
> the code.
>
> Signed-off-by: Geliang Tang
> ---
> Changes in v2:
> - drop the coding style fixing in v1.
> ---
> drivers/staging/rtl8723au/core/rtw_ap.c | 92
> ++-
>
Hi Maarten,
2016-02-02 Maarten Lankhorst :
> Op 02-02-16 om 14:23 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Making fence_info a pointer enables us to extend the struct in the future
> > without breaking the ABI.
> >
> > v2: use type __u64 for fence_info
> > Signed-off-by:
On Monday 01 February 2016 18:07:45 Joao Pinto wrote:
> This patch adds a new driver that will be the reference platform driver
> for all PCI RC IP Protoyping Kits based on ARC SDP.
> This patch is composed by:
>
> -MAINTAINERS file was updated to include the new driver
>
From: Michal Hocko
sh and xtensa seem to be the only architectures which use explicit
memory barriers for rw_semaphore operations even though they are not
really needed because there is the full memory barrier is always implied
by atomic_{inc,dec,add,sub}_return resp. cmpxchg. Remove them.
From: Michal Hocko
This is no longer used anywhere and all callers (__down_write) use
0 as a subclass. Ditch __down_write_nested to make the code easier
to follow.
This shouldn't introduce any functional change.
Signed-off-by: Michal Hocko
---
arch/s390/include/asm/rwsem.h | 7 +--
Hi,
the following patchset implements a killable variant of write lock for
rw_semaphore. My usecase is to turn as many mmap_sem write users to use
a killable variant which will be helpful for the oom_reaper [1] to
asynchronously tear down the oom victim address space which requires
mmap_sem for
Madhavan Srinivasan [ma...@linux.vnet.ibm.com] wrote:
>
>
> On Saturday 30 January 2016 08:37 AM, Sukadev Bhattiprolu wrote:
> > From a1aa992fb25fb8e98a5c5724376ae8cc91463de3 Mon Sep 17 00:00:00 2001
> > From: Sukadev Bhattiprolu
> > Date: Mon, 25 Jan 2016 23:05:36 -0500
> > Subject: [PATCH
From: Michal Hocko
Now that all the architectures implement the necessary glue code
we can introduce down_write_killable. The only difference wrt. regular
down_write is that the slow path waits in TASK_KILLABLE state and the
interruption by the fatal signal is reported as -EINTR to the caller.
From: Michal Hocko
x86 implementation of __down_write is using inline asm to optimize the
code flow. This however requires that it has go over an additional hop
for the slow path call_rwsem_down_write_failed which has to
save_common_regs/restore_common_regs to preserve the calling convention.
From: Michal Hocko
which is uses the same fast path as __down_write except it falls back to
rwsem_down_write_failed_killable slow path and return -EINTR if killed.
Signed-off-by: Michal Hocko
---
arch/sparc/include/asm/rwsem.h | 13 +
1 file changed, 13 insertions(+)
diff --git
On Tue, Feb 2, 2016 at 11:57 AM, Viresh Kumar wrote:
> This extra macro is required because the variable min_sampling_rate is
> made part of 'struct dbs_data' instead of governor specific tunables.
>
> For further optimization, its better that we kill
> declare_show_sampling_rate_min() by moving
From: Michal Hocko
which is uses the same fast path as __down_write except it falls back to
rwsem_down_write_failed_killable slow path and return -EINTR if killed.
Signed-off-by: Michal Hocko
---
arch/x86/include/asm/rwsem.h | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Michal Hocko
which is uses the same fast path as __down_write except it falls back to
rwsem_down_write_failed_killable slow path and return -EINTR if killed.
Signed-off-by: Michal Hocko
---
arch/xtensa/include/asm/rwsem.h | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Michal Hocko
Introduce ___down_write for the fast path and reuse it for __down_write
resp. __down_write_killable each using the respective generic slow path
(rwsem_down_write_failed resp. rwsem_down_write_failed_killable).
Signed-off-by: Michal Hocko
---
arch/s390/include/asm/rwsem.h |
From: Michal Hocko
Introduce ___down_write for the fast path and reuse it for __down_write
resp. __down_write_killable each using the respective generic slow path
(rwsem_down_write_failed resp. rwsem_down_write_failed_killable).
Signed-off-by: Michal Hocko
---
arch/alpha/include/asm/rwsem.h |
From: Michal Hocko
which is uses the same fast path as __down_write except it falls back to
rwsem_down_write_failed_killable slow path and return -EINTR if killed.
Signed-off-by: Michal Hocko
---
arch/sh/include/asm/rwsem.h | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Michal Hocko
Introduce ___down_write for the fast path and reuse it for __down_write
resp. __down_write_killable each using the respective generic slow path
(rwsem_down_write_failed resp. rwsem_down_write_failed_killable).
Signed-off-by: Michal Hocko
---
arch/ia64/include/asm/rwsem.h |
From: Michal Hocko
Introduce a generic implementation necessary for down_write_killable.
This is a trivial extension of the already existing down_write call
which can be interrupted by SIGKILL. This patch doesn't provide
down_write_killable yet because arches have to provide the necessary
On Tue, Feb 02, 2016 at 10:59:41AM -0800, Dan Williams wrote:
> True, but in this case we're just trying to resolve the bdev for a
> inode / sector combination to already allocated storage. So
> get_block() is a misnomer, this is just get_bdev() to resolve a
> super_block-inode+sector tuple to a
On Tue, Feb 02, 2016 at 04:19:44PM +, Marc Zyngier wrote:
> On 02/02/16 15:46, Christoffer Dall wrote:
> > On Tue, Feb 02, 2016 at 09:46:05AM +, Marc Zyngier wrote:
> >> On 01/02/16 13:54, Christoffer Dall wrote:
> >>> On Mon, Jan 25, 2016 at 03:53:44PM +, Marc Zyngier wrote:
> A
On Tue, Feb 2, 2016 at 11:57 AM, Viresh Kumar wrote:
> Hi Rafael,
>
> Sorry for doing this, I know you were also looking to fix this in a
> possibly different way. But I thought, it would be better if we fix
> that. We can scrap this version and take yours if that looks better.
That's not nice
On Tue, Feb 02, 2016 at 05:39:16PM +, Joao Pinto wrote:
> Driver name changed but not updated in MAINTAINERS.
>
> Signed-off-by: Joao Pinto
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d2e4506..caba688
phy-am335x.c doesn't use any interfaces from linux/regulator/consumer.h, so
stop including it.
Signed-off-by: Bjorn Helgaas
CC: Sebastian Andrzej Siewior
---
drivers/usb/phy/phy-am335x.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/phy/phy-am335x.c
In include/linux/usb/usb_phy_generic.h, use a forward declaration for
struct gpio_desc instead of including linux/gpio/consumer.h.
Of the files that include usb_phy_generic.h, only
drivers/usb/phy/phy-generic.c uses the gpiod_*() interfaces from
linux/gpio/consumer.h, so include consumer.h
In drivers/usb/phy/phy-generic.h, use forward declarations for struct
regulator and struct gpio_desc instead of including
linux/regulator/consumer.h and linux/gpio/consumer.h.
phy-generic.c is included three places (phy-am335x.c, phy-generic.c,
phy-keystone.c). Of these, phy-am335x.c and
Remove some gpio and regulator #includes when they can be replaced by
trivial forward struct declarations. Also move a linux/gpio/consumer.h
#include from a header to the single .c files that uses it.
---
Bjorn Helgaas (3):
usb: phy: generic: use forward declarations instead of #includes
On Tuesday 02 February 2016 11:47:13 Stephen Boyd wrote:
> On 02/02, Arnd Bergmann wrote:
> > On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
> >
> > I see what you mean now. I checked different gcc versions, and with my
> > patch I get
> > the warnings for 4.6 through 4.9, but not for
On Tue, Feb 2, 2016 at 11:30 AM, Will Deacon wrote:
>
> FWIW, and this is by no means conclusive, I hacked that up quickly and
> ran hackbench a few times on the nearest idle arm64 system. The results
> were consistently ~4% slower using acquire for rcu_dereference.
Ok, that's *much* more
On Tue, Feb 02, 2016 at 01:15:13PM +, Li, Liang Z wrote:
> > >> We found dom0 will crash when booing on HSW-EX server, the dom0
> > >> kernel version is v4.4. By debugging I found the your patch '
> > >> x86/xen: discard RAM regions above the maximum reservation' , which
> > the commit ID is :
Hi Yury,
On Tue, Feb 02, 2016 at 05:08:26PM +0100, Heiko Carstens wrote:
> See e.g. 485d52768685 ("sys_personality: change sys_personality() to accept
> "unsigned int" instead of u_long") would have been a candidate which could
> silently break architectures which need compat wrappers.
Ok, this
Most arches have an asm/gpio.h that merely includes linux/gpio.h. The
others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected,
linux/gpio.h includes asm/gpio.h.
Therefore, code should include linux/gpio.h instead of including asm/gpio.h
directly.
Remove includes of asm/gpio.h, adding an
asm/gpio.h is included only by linux/gpio.h, and then only when the arch
selects ARCH_HAVE_CUSTOM_GPIO_H. Only the following arches select it: arm
avr32 blackfin m68k (COLDFIRE only) sh unicore32.
Remove the unused asm/gpio.h files for the arches that do not select
ARCH_HAVE_CUSTOM_GPIO_H.
This
Many arches supply an asm/gpio.h that contains only this:
#warning Include linux/gpio.h instead of asm/gpio.h
#include
These two patches change all the places that include asm/gpio.h
so they include linux/gpio.h instead, and then remove the asm/gpio.h
files.
There are several arches that
On Tue, Feb 02 2016, Andrew Morton wrote:
> On Thu, 28 Jan 2016 15:14:17 +0200 Andy Shevchenko
> wrote:
>
>> + * @array: array of strings
>> + * @n: number of strings in the array or -1 for NULL
>> terminated arrays
>> + * @string: string to match with
>> + *
>> + * Return:
>> +
This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
---
No changes from v7.
include/trace/events/power.h | 22 ++
On 02/02, Arnd Bergmann wrote:
> On Monday 01 February 2016 17:15:45 Stephen Boyd wrote:
>
> I see what you mean now. I checked different gcc versions, and with my patch
> I get
> the warnings for 4.6 through 4.9, but not for 5.x.
>
> In general, I tried to only address warnings I still see
In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the
CPU when the chip crosses its thermal and power limits. Currently,
powernv-cpufreq driver detects and reports this event as a console
message. Some machines may not sustain the max turbo frequency in all
conditions and can be
Currently we use printk message to notify the throttle event. But this
can flood the console if the cpu is throttled frequently. So replace the
printk with the tracepoint to notify the throttle event. And also events
like throttle below nominal frequency and OCC_RESET are reduced to
cpu_to_chip_id() does a DT walk through to find out the chip id by
taking a contended device tree lock. This adds an unnecessary overhead
in a hot path. So instead of calling cpu_to_chip_id() everytime cache
the chip ids for all cores in the array 'core_to_chip_map' and use it
in the hotpath.
Create sysfs attributes to export throttle information in
/sys/devices/system/cpu/cpufreq/chipX. The newly added sysfs files are as
follows:
1)/sys/devices/system/cpu/cpufreq/chipX/throttle_table
This table gives the detailed information on number of times Pmax is
limited to different frequencies
In the kworker_thread powernv_cpufreq_work_fn(), we can end up
sending an IPI to a cpu going offline. This is a rare corner case
which is fixed using {get/put}_online_cpus(). Along with this fix,
this patch adds changes to do oneshot cpumask_{clear/and} operation.
Suggested-by: Shreyas B Prabhu
This will free the dynamically allocated memory of 'chips' on
module exit.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Gautham R. Shenoy
Acked-by: Viresh Kumar
---
Changes from v7:
- Minor typo fix in the commit message
drivers/cpufreq/powernv-cpufreq.c | 1 +
1 file changed, 1 insertion(+)
On Mon, 1 Feb 2016, Jeffrey Merkey wrote:
> If a debugger is loaded it will not crash, just enter the debugger.
> But yes, it will int3 if set and no debugger has been loaded to handle
> the int3 condition. Hmmm. Maybe its better just to skip calling
> pr_emerg and put this logic as a single
include/asm-generic/pci-bridge.h is now empty, so remove every #include of
it.
Signed-off-by: Bjorn Helgaas
---
arch/alpha/include/asm/pci.h |1 -
arch/arm/include/asm/pci.h|3 ---
arch/arm64/include/asm/pci.h |1 -
arch/mips/include/asm/pci.h
On Tue, Feb 2, 2016 at 6:01 PM, Juri Lelli wrote:
> Hi Rafael,
>
> On 02/02/16 17:35, Rafael J. Wysocki wrote:
>> On Tue, Feb 2, 2016 at 4:47 PM, Juri Lelli wrote:
>> > Hi Viresh,
>> >
>> > On 02/02/16 16:27, Viresh Kumar wrote:
>> >> Until now, governors (ondemand/conservative) were using the
On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote:
> On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:
> > None of this is answering my question - I know what the current API is,
> > describing it doesn't tell me about actual users or how they are able to
> > sensibly use the
Drivers should include asm/pci-bridge.h only when they need the arch-
specific things provided there. Outside of the arch/ directories, the only
drivers that actually need things provided by asm/pci-bridge.h are the
powerpc RPA hotplug drivers in drivers/pci/hotplug/rpa*.
Remove the includes of
On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote:
> On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote:
> > None of this is answering my question - I know what the current API is,
> > describing it doesn't tell me about actual users or how they are able to
> > sensibly use the
arm64 generates asm/pci-bridge.h, which merely includes the now-empty
asm-generic/pci-bridge.h. Stop generating asm/pci-bridge.h, and stop
including it.
Signed-off-by: Bjorn Helgaas
---
arch/arm64/include/asm/Kbuild |3 ---
arch/arm64/kernel/pci.c |2 --
2 files changed, 5
include/asm-generic/pci-bridge.h is empty, and nobody includes it, so
remove it.
Signed-off-by: Bjorn Helgaas
---
include/asm-generic/pci-bridge.h |9 -
1 file changed, 9 deletions(-)
delete mode 100644 include/asm-generic/pci-bridge.h
diff --git a/include/asm-generic/pci-bridge.h
Removed blank line after curly braces.
Found using checkpatch.pl.
Signed-off-by: Bhumika Goyal
---
drivers/staging/octeon/ethernet-rgmii.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/octeon/ethernet-rgmii.c
b/drivers/staging/octeon/ethernet-rgmii.c
index
The PCI flag management constants and functions were previously declared in
include/asm-generic/pci-bridge.h. But they are not specific to bridges,
and arches did not include pci-bridge.h consistently.
Move the following interfaces and related constants to include/linux/pci.h
and remove
We've had some non-arch-specific stuff (pci_has_flag() and associated
definitions like PCI_PROBE_ONLY) in asm/pci-bridge.h. This leads to
warnings like:
drivers/pci/host/pcie-designware.c:562:20: error: 'PCI_PROBE_ONLY' undeclared
(first use in this function)
On Tue, Feb 02, 2016 at 11:44:38AM +0800, Caesar Wang wrote:
> This patch adds the mclk property for the CODEC driver,
> since sometimes the CODEC driver needs the clock enabled.
This appears to be a resend of a patch that's already been applied. If
any changes are required please send
On Tue, Feb 02, 2016 at 10:06:36AM -0800, Linus Torvalds wrote:
> On Tue, Feb 2, 2016 at 9:51 AM, Will Deacon wrote:
> >
> > Given that the vast majority of weakly ordered architectures respect
> > address dependencies, I would expect all of them to be hurt if they
> > were forced to use barrier
On Tue, Feb 2, 2016 at 10:29 AM, Hannes Frederic Sowa
wrote:
>>
>> Anyway, can someone provide a high-level description of what exactly
>> this patch is supposed to do? Which operation should be limited, who
>> should inflight FDs be accounted on, and which rlimit should be used
>> on each
On Tue, 2 Feb 2016 22:31:06 +0900
Masanari Iida wrote:
> This patch fix spelling typos found in DocBook/filesystem.xml.
> It is because the file was generated from comments in code,
> I have to fix the comments in codes, instead of xml file.
As Randy said, "tradeoff" is fine. This should
On 02/02/2016 10:44 AM, Philipp Zabel wrote:
Hi Andrew,
I like the idea to introduce a generic binding in principle, but it
should be able to cover a lot of the cases in the wild. And I'm not sure
we know this to be the case yet.
Currently we have three syscon users in drivers/reset:
On Mon, Feb 01, 2016 at 10:34:23PM +0900, Takashi Sakamoto wrote:
> Well, I don't mind to receive them because it's a good information for
> me to get current state of ALSA core functionality. If I had some
> spare time, I was also going to fix it. But currently I have little
> time for it due to
Previously we had this:
if (wakeup)
ret = enable_irq_wake(...);
if (!wakeup || ret)
...
"ret" is only evaluated when "wakeup" is true, and it is always initialized
in that case, but gcc isn't smart enough to figure that out and warns:
drivers/pci/pcie/pme.c:414:14: warning: 'ret'
We've already looked up srv->port a few lines earlier, and there's no need
to do it again. Remove the redundant lookup.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pcie/pme.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index
Previously we checked the device_attach() return value only when
CONFIG_BUG=y. That caused this warning in builds where CONFIG_BUG is not
set:
drivers/pci/bus.c:237:6: warning: variable 'retval' set but not used
[-Wunused-but-set-variable]
Check the return value of device_attach() always and
I'm on a quest to clean up compiler warnings in drivers/pci. I'd like to
be able to treat warnings as errors, at least for the 0day build robot.
---
Bjorn Helgaas (3):
PCI: Check device_attach() return value always
PCI/PME: Remove redundant port lookup
PCI/PME: Restructure
On Tue, Feb 02, 2016 at 03:49:52PM +0100, codekip...@gmail.com wrote:
> Marcus Cooper (2):
> dt-bindings: add sun4i SPDIF transceiver bindings
> ASOC: sunxi: Add support for the SPDIF block
Please do try to use subject lines matching the style for the subsystem.
signature.asc
Description:
On Mon, 01 Feb 2016 07:34:22 +1100, Stephen Rothwell said:
> Hi Jesper,
> > [PATCH] mm: temporary fix for SLAB in linux-next
> >
> > From: Jesper Dangaard Brouer
> >
> > This is only for linux-next, until AKPM pickup fixes two patches:
> > base url: http://ozlabs.org/~akpm/mmots/broken-out/
> >
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: David Gibson
commit 35a4933a895927990772ae96fdcfd2f806929ee2 upstream.
1e75fa8 "time: Condense timekeeper.xtime into xtime_sec"
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Ilia Mirkin
commit 4761703bd04bbdf56396d264903cc5a1fdcb3c01 upstream.
Several users have, over time, reported issues with MSI on
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Hans de Goede
commit 0a363e85cdafbc6a49b91c604d0d4d070dc7 upstream.
MSI interrupts appear to not work for nv46 based cards.
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Ilia Mirkin
commit fa8c9ac72fe0bcdf5bc7cc84e85cc2a1af53f9fd upstream.
See https://bugs.freedesktop.org/show_bug.cgi?id=74492
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Oliver Neukum
commit 1eaf35e4dd592c59041bc1ed3248c46326da1f5f upstream.
The module should fail to load.
Signed-off-by: Oliver Neukum
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Paolo Bonzini
commit aba2f06c070f604e388cf77b1dcc7f4cf4577eb0 upstream.
Poor #AC was so unimportant until a few days ago that we were
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Malcolm Priestley
commit c9d57de6103e343f2d4e04ea8d9e417e10a24da7 upstream.
When in FE_TUNE_MODE_ONESHOT the frontend must report
the
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Antonio Ospite
commit dcc7fdbec53a960588f2c40232db2c6466c09917 upstream.
v4l2-compliance sends a zeroed struct v4l2_streamparm in
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Steven Rostedt
commit 32abc2ede536aae52978d6c0a8944eb1df14f460 upstream.
When a long value is read on 32 bit machines for 64 bit
Hello Enric,
On 01/16/2016 07:51 AM, Enric Balletbo i Serra wrote:
The MCLK is provided by an external clock of 24.576MHz.
Signed-off-by: Enric Balletbo i Serra
---
arch/arm/boot/dts/am335x-sl50.dts | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git
On Tue, Feb 2, 2016 at 10:46 AM, Matthew Wilcox wrote:
> On Tue, Feb 02, 2016 at 09:46:21AM -0800, Dan Williams wrote:
>> What a about a super_operation? That seems the right level, given
>> we're currently doing:
>>
>> inode->i_sb->s_bdev
>>
>> ...it does not seem terrible to instead do:
>>
>>
Hi Sergeev,
Your are right. I will merge it.
Thanks.
Acked-by: Lennox Wu
2016-02-01 0:21 GMT+08:00 Stas Sergeev :
>
> Currently get_sigframe() checks only
> (ka->sa.sa_flags & SA_ONSTACK) && (!on_sig_stack(sp))
> to determine whether the switch to sigaltstack is needed.
> It forgets to checks
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: John Blackwood
commit 5db4fd8c52810bd9740c1240ebf89223b171aa70 upstream.
Make sure to clear out any ptrace singlestep state when a
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Alex Deucher
commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 upstream.
Need to call this on resume if displays changes during
suspend
Hello Enric,
On 01/16/2016 07:51 AM, Enric Balletbo i Serra wrote:
UART0 device is the device to be used for boot console output.
Signed-off-by: Enric Balletbo i Serra
---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Uri Mashiach
commit 9b2761cb72dc41e1948c8a5512b4efd384eda130 upstream.
The maximum chunks used by the function is
On Tue, 2016-02-02 at 19:39 +0100, Ksenija Stanojevic wrote:
> Move panel driver from drivers/staging/panel to drivers/misc.
>
> Signed-off-by: Ksenija Stanojevic
> ---
> Changes in v3:
> - modify driver location in MAINTAINERS file
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Borislav Petkov
commit fcd5c4dd8201595d4c598c9cca5e54760277d687 upstream.
EDAC workqueue destruction is really fragile. We cancel
On 02/02/2016 08:11 AM, Vlastimil Babka wrote:
>> +void __weak arch_show_smap(struct seq_file *m, struct vm_area_struct
>> *vma)
>> +{
>> +}
>
> Is it valid that this serves also as a declaration? Or should it be also
> in some header?
I guess having it in a header would make it less likely that
3.13.11-ckt34 -stable review patch. If anyone has any objections, please let
me know.
---8<
From: Borislav Petkov
commit 12e26969b32c79018165d52caff3762135614aa1 upstream.
I get the splat below when modprobing/rmmoding EDAC
401 - 500 of 2334 matches
Mail list logo
