On Friday, January 31, 2014 05:56:30 PM Yinghai Lu wrote:
On Fri, Jan 31, 2014 at 3:34 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
[...]
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 4ff36bfa785e..b8c93c90daf5 100644
On 2/1/2014 4:24 AM, Sergei Shtylyov wrote:
Hello.
On 01/31/2014 06:08 PM, Alexander Gordeev wrote:
[...]
+if (status 0)
+goto disable_msix;
Hm, if enabling MSI failed, we don't need to disable it, right? So,
perhaps the label should be renamed?
The code
Call platform_set_drvdata before devm_iio_device_register to avoid possible
race condition when accessing driver data.
Signed-off-by: Johannes Thumshirn morbid...@gmail.com
---
drivers/iio/adc/viperboard_adc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On 02/01/2014 03:39 PM, Johannes Thumshirn wrote:
Call platform_set_drvdata before devm_iio_device_register to avoid possible
race condition when accessing driver data.
I don't think the driver data is accessed from within any of the IIO device
callbacks. In fact I don't think it is accessed at
On Sat, Feb 01, 2014 at 03:46:05PM +0100, Lars-Peter Clausen wrote:
On 02/01/2014 03:39 PM, Johannes Thumshirn wrote:
Call platform_set_drvdata before devm_iio_device_register to avoid possible
race condition when accessing driver data.
I don't think the driver data is accessed from within
Am Donnerstag, den 30.01.2014, 16:10 -0800 schrieb Andi Kleen:
@@ -1335,7 +1335,6 @@ config ARCH_SPARSEMEM_ENABLE
config ARCH_SPARSEMEM_DEFAULT
def_bool y
- depends on X86_64
Is that really needed? Why does the vdso need sparsemem?
No, it is from the previous patch. I will
Drop call to platform_set_drvdata as driver data is not used anywhere in the
driver
Signed-off-by: Johannes Thumshirn morbid...@gmail.com
---
drivers/iio/adc/viperboard_adc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/iio/adc/viperboard_adc.c b/drivers/iio/adc/viperboard_adc.c
On 01/14/2014 11:24 AM, Pavel Roskin wrote:
Hi Alan,
Quoting One Thousand Gnomes gno...@lxorguk.ukuu.org.uk:
Maybe we should unset the low_latency flag as soon as DMA fails? There
are two flags, one is state-uart_port-flags and the other is
port-low_latency. I guess we need to unset both.
Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but
it would not adjust
the FINFO properly, resulting in distorted screen rendering. The patch corrects
that behaviour.
See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.
Signed-off-by: Christopher Friedt
From: Stefani Seibold stef...@seibold.net
This patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
and vdso_time() to the 32 bit VDSO.
The reason to do this was to get a fast reliable time stamp. Many developers
uses TSC to get a fast time stamp, without knowing the pitfalls. VDSO
From: Stefani Seibold stef...@seibold.net
This patch add the VDSO time support for the IA32 Emulation Layer.
Due the nature of the kernel headers and the LP64 compiler where the
size of a long and a pointer differs against a 32 bit compiler, there
is a lot of type hacking necessary.
This kind
From: Stefani Seibold stef...@seibold.net
This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
For 32 bit programs running on a 32 bit kernel, the same mechanism is
used as for 64 bit programs running on a 64 bit kernel.
Signed-off-by: Stefani Seibold stef...@seibold.net
---
From: Stefani Seibold stef...@seibold.net
This patch move the vsyscall_gtod_data handling out of vsyscall_64.c
into an additonal file vsyscall_gtod.c to make the functionality
available for x86 32 bit kernel.
It also adds a new vsyscall_32.c which setup the VVAR page.
Signed-off-by: Stefani
From: Stefani Seibold stef...@seibold.net
The _install_special_mapping() is the new base function for
install_special_mapping(). This function will return a pointer of the
created VMA or a error code in an ERR_PTR()
This new function will be needed by the for the vdso 32 bit support to map the
On Sat, 1 Feb 2014, Brown, Len wrote:
Right now (on ARM at least but I imagine this is pretty universal), the
biggest impact on information accuracy for a CPU depends on what the
other CPUs are doing. The most obvious example is cluster power down.
For a cluster to be powered down, all
On Sat, Feb 01, 2014 at 06:00:40AM +, Brown, Len wrote:
Right now (on ARM at least but I imagine this is pretty universal), the
biggest impact on information accuracy for a CPU depends on what the
other CPUs are doing. The most obvious example is cluster power down.
For a cluster to
init_inodecache is only called by __init init_udf_fs.
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/udf/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/udf/super.c b/fs/udf/super.c
index 3306b9f..6a14649 100644
--- a/fs/udf/super.c
+++ b/fs/udf/super.c
@@
Andy Lutomirski wrote:
The HPET is so amazingly slow that this is barely a win.
What happens on CPUs where the TSC cannot be used for the clock?
it scares me a tiny bit to map a piece of crappy hardware where every
userspace program can poke at it (even if said poking is read-only).
Let's
init_inodecache is only called by __init init_ext2_fs.
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/ext2/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 20d6697..73d80da 100644
--- a/fs/ext2/super.c
+++
Hello,
On Thu, Jan 30, 2014 at 10:46 PM, Jenny Tc jenny...@intel.com wrote:
Do we have any mailing list for power_supply subsystem? If not what about
having
one - linux-power-sup...@vger.kernel.org?
I'm not sure that if that ML will have enough traffic to be fully
usefull or enough
Hello,
On Thu, Jan 30, 2014 at 5:32 PM, Krzysztof Kozlowski
k.kozlow...@samsung.com wrote:
Fix NULL pointer dereference of chip-pdata if platform_data was not
supplied to the driver.
The driver during probe stored the pointer to the platform_data:
chip-pdata =
Hi there -
finally I prepared a patch for the famous ftdi_sio usb serial driver.
Adding two Tagsys RFID readers I am using.
After having asked Bill Ryder he suggested adressing the
linux-usb-devel mailing list. (what?)
Sorry for the mess below - I am not doing this frequently - being
rather a
On 02/01/2014 04:13 AM, Petr Tesarik wrote:
Just curious, but
what the heck kind of 32-bit NUMA hardware is still in the wild? Did
someon buy a NUMA-Q on eBay? :)
In fact, this is a patch that has been floating around in SUSE
Enterprise kernels for some time. It was originally added to
On Mon, Dec 23, 2013 at 09:39:22PM +0100, Jan Kara wrote:
Block layer currently abuses rq-csd.list.next for storing fifo_time.
That is a terrible hack and completely unnecessary as well. Union
achieves the same space saving in a cleaner way.
Signed-off-by: Jan Kara j...@suse.cz
Hi Jan,
On Fri, Jan 31, 2014 at 02:24:42PM -0800, Andrew Morton wrote:
On Wed, 29 Jan 2014 22:24:11 -0600 Rob Landley r...@landley.net wrote:
On 01/29/14 18:27, Henrik Austad wrote:
Some of the 00-INDEX files are somewhat outdated and some folders does not
contain 00-INDEX at all. Only outdated
On 02/01, Rakib Mullick wrote:
On Thu, Jan 30, 2014 at 1:02 PM, Rakib Mullick rakib.mull...@gmail.com
wrote:
On Thu, Jan 30, 2014 at 12:32 AM, Oleg Nesterov o...@redhat.com wrote:
On 01/29, Rakib Mullick wrote:
Are you thinking that , since things are not broken, then we shouldn't
On Sat, Feb 1, 2014 at 7:43 AM, Clemens Ladisch clem...@ladisch.de wrote:
Andy Lutomirski wrote:
The HPET is so amazingly slow that this is barely a win.
What happens on CPUs where the TSC cannot be used for the clock?
vclock_gettime, etc will fall back to using syscalls, just like they
would
The TDA998x HDMI transmitter accepts audio input from either I2S or
S/PDIF.
Theses inputs have different intrinsic constraints and these constraints
may be modified by the audio parameters of the connected video device.
The choice of I2S or S/PDIF may be the done by the user or by automatic
This patch adds the DT documentation of the NXP TDA998x CODEC.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt
This patch adds a CODEC driver for the NXP TDA998x HDMI transmitter.
The CODEC handles both I2S and S/PDIF input and does dynamic input
switch in the TDA998x I2C driver on start/stop audio streaming.
This driver is DT only and it is loaded from its DT description as
a subnode in the TDA998x
The supported audio parameters are described in the EDID which is
received by the HDMI transmitter from the connected screen.
Use these ones to adjust the audio stream parameters.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/gpu/drm/i2c/tda998x_drv.c | 15
In some boards, with I2S input, the NXP TDA998x HDMI transmitter did
not play audio streams with a sample width lower than S16_32.
This patch adjusts the CTS_N predivider according to the used sample
width.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
drivers/gpu/drm/i2c/tda998x_drv.c
When both I2S and S/PDIF are wired from the audio device to the
TDA998x, the user or some internal mechanism may choose to do audio
streaming via either inputs.
This patch adds an exported function in the TDA998x driver which
initializes the audio input parameters according to the audio
On Fri, Jan 31, 2014 at 02:31:11PM +0100, Maxime Ripard wrote:
On Fri, Jan 31, 2014 at 12:12:15PM +, Mark Brown wrote:
This seems confusing - the idea here is that if we've handed the device
off to the managed function then the managed function deals with
destroying it. Note that
I am announcing the release of the Linux 3.8.13.17 kernel.
The updated 3.8.y tree can be found at:
git://kernel.ubuntu.com/ubuntu/linux.git linux-3.8.y
and can be browsed at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.8.y;a=shortlog
The diff from v3.8.13.16 is
diff --git a/Makefile b/Makefile
index 7d89342..54a09a9 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 3
PATCHLEVEL = 8
SUBLEVEL = 13
-EXTRAVERSION = .16
+EXTRAVERSION = .17
NAME = Remoralised Urchins Update
# *DOCUMENTATION*
diff --git
On Sat, Feb 01, 2014 at 04:02:02PM +0800, Fabian Frederick wrote:
init_inodecache is only called by __init init_ext2_fs.
Looks like this is true for the majority of filesystems. Would you care
to submit more patches? :-)
--
Matthew Wilcox Intel Open Source Technology
read_buf is called in place of write_buf in the
nand_write_page_raw_syndrome function.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
drivers/mtd/nand/nand_base.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/nand_base.c
On Sat, 1 Feb 2014 10:53:34 -0700
Matthew Wilcox matt...@wil.cx wrote:
On Sat, Feb 01, 2014 at 04:02:02PM +0800, Fabian Frederick wrote:
init_inodecache is only called by __init init_ext2_fs.
Looks like this is true for the majority of filesystems. Would you care
to submit more patches?
On 01/31/2014 06:44 PM, Andy Gross wrote:
On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
Hi Lars,
On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen l...@metafoo.de wrote:
On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
On Sat, Feb 1, 2014 at 6:38 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
Updated revert follows.
I'm taking this directly, since I'll cut rc1 tomorrow (or maybe later today).
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
Hello.
On 01-02-2014 20:48, Jean-Francois Moine wrote:
This patch adds the DT documentation of the NXP TDA998x CODEC.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 17 +
1 file changed, 17 insertions(+)
On Sat, Feb 01, 2014 at 03:38:29PM +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Subject: Revert PCI: Remove from bus_list and release resources in
pci_release_dev()
Revert commit ef83b0781a73 PCI: Remove from bus_list and release
resources in
On Fri, Jan 31, 2014 at 6:32 AM, Greg KH gre...@linuxfoundation.org wrote:
Here's a single staging driver for a wireless chipset that has shown up
in the SteamBox hardware. It is merged separately from the main
staging pull request to sync up with the wireless api changes that came
in from
On Wed, Jan 29, 2014 at 01:03:52PM -0600, Nishanth Menon wrote:
To help us debug similar problems, I wrote a tool today:
https://github.com/nmenon/ctt-dump - it is a simple memory read utility,
Input file is CTT dump-out
For example: 3630 CTT is here:
Hello!
On Jan 30, 2014, at 12:48 PM, Dave Jones wrote:
This probably made more sense when the code supported multiple protocol
versions,
but now it's just obfuscation.
Signed-off-by: Dave Jones da...@fedoraproject.org
diff --git a/drivers/staging/lustre/lustre/ptlrpc/pack_generic.c
On Wed, Jan 29, 2014 at 04:57:00PM +0200, Tero Kristo wrote:
Hmm, well, the omap96m_alwon_fck rate is still wrong. Try adding
ti,min-div = 2; and ti,max-div = 4; to properties of the clock
node.
Hmm, doesn't change anything here.
Thanks
-- Christoph
--
To unsubscribe from this list: send
On Fri, Jan 31, 2014 at 2:37 PM, H. Peter Anvin h...@linux.intel.com wrote:
Here is a patch for comments/review/opinions... it has only been
compile-tested.
Looks sane to me from a superficial quick read-through.
Linus
--
To unsubscribe from this list: send the line unsubscribe
init_inodecache is only called by __init init_ext4_fs.
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 1f7784d..9a387b8 100644
--- a/fs/ext4/super.c
+++
init_inodecache is only called by __init init_ext3_fs.
Signed-off-by: Fabian Frederick f...@skynet.be
---
fs/ext3/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 37fd31e..94608d4 100644
--- a/fs/ext3/super.c
+++
I have nothing against this series of patches, but appreciate it going
through the kconfig maintainer, since we have one.
Michal added to the participants. Dave, I don't think the patches
themselves were cc'd to Michal either, but I didn't check.
Linus
On Fri, Jan 31, 2014 at 9:24
On Thu, Jan 30, 2014 at 11:33 PM, Suresh Siddha sbsid...@gmail.com wrote:
a. delayed dynamic allocation of FPU state area was not a good idea
(from me). Given most of the future cases will be anyway using eager
FPU (because of processor features like xsaveopt etc, applications
implicitly
On 02/01/2014 11:27 AM, Linus Torvalds wrote:
(a) we don't want to restore at all, because once the kernel starts
using math, it might do so a lot, and saving/restoring is a bad idea:
void __kernel_fpu_end(void)
{
stts();
}
*or*
Quite frankly, I'd almost lean towards
And your point is?
It is a bad idea for an individual CPU to track the C-state
of another CPU, which can change the cycle after it was checked.
We know it is a bad idea because we used to do it,
until we realized code here can easily impact the
performance critical path.
In general, it is the
On Sat, Feb 1, 2014 at 11:35 AM, H. Peter Anvin h...@zytor.com wrote:
This will obviously not protect eageronly features (MPX, LWP, ...) so this
means those features are permanently unavailable to the kernel, even inside
kernel_fpu_begin/end. Now, currently I don't think we have any plans to
Of course, if we are really doing all eager fpu, we could just leave cr0.ts
always clear and not touch it at all...
On February 1, 2014 11:46:15 AM PST, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sat, Feb 1, 2014 at 11:35 AM, H. Peter Anvin h...@zytor.com wrote:
This will
On Sat, 1 Feb 2014, Brown, Len wrote:
And your point is?
It is a bad idea for an individual CPU to track the C-state
of another CPU, which can change the cycle after it was checked.
Absolutely. And I'm far from advocating we do this either.
We know it is a bad idea because we used to do
Commit ad6492b8 added much needed memblock_virt_alloc_low() and further
commit 07bacb3 {memblock, bootmem: restore goal for alloc_low} fixed the
issue with low memory limit thansk to Yinghai. But even after all these fixes,
there is still one case where the limit check done with
On Sat, Feb 1, 2014 at 12:00 PM, H. Peter Anvin h...@zytor.com wrote:
Of course, if we are really doing all eager fpu, we could just leave cr0.ts
always clear and not touch it at all...
That's what the eager fpu code tries to do now (apart from process
initialization, I think). But the problem
On 02/01/2014 11:46 AM, Linus Torvalds wrote:
.. which *does* actually bring up something that might work, and might
be a good idea: remove the restore math state or set TS from the
normal kernel paths *entirely*, and move it to the return to user
space phase.
The task switch code would
Hi Linus,
please pull the latest updates for the parisc architecture from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-for-3.14
The three major changes in this patchset is a implementation for flexible
userspace memory maps, cache-flushing fixes (again), and
Hi Linus,
See tag for branch contents. As you'll see, the commit dates are recent;
we've mostly collected these fixes in the last few days but I also had
to rebuild the branch yesterday to sort out some internal conflicts
which reset the timestamps. The changes should have been tested by each
On 02/01/2014 07:32 AM, stef...@seibold.net wrote:
This kind of type hacking could be prevent in the future by doing a call to
the
64 bit code by the following sequence:
- Compile the arch/x86/vdso/vclock_gettime.c as 64 bit, but only generate
the assembler output.
- Next compile a 32
2014-01-31 Eric Dumazet eric.duma...@gmail.com:
On Fri, 2014-01-31 at 22:11 +0200, Tommi Rantala wrote:
Hello,
Hit this while fuzzing v3.13-9218-g0e47c96 with trinity in a qemu
virtual machine.
Tommi
Hi Tommi
Could you please try the following fix ?
Thanks, giving this a spin. This
Hi Linus,
Please pull these patches to update the turbostat utility.
thanks!
Len Brown, Intel Open Source Technology Center
The following changes since commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6:
Linux 3.13-rc8 (2014-01-12 17:04:18 +0700)
are available in the git repository at:
(re-sent with correct from: address - gmail fun...)
Hi Linus,
Please pull these patches to update the turbostat utility.
thanks!
Len Brown, Intel Open Source Technology Center
The following changes since commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6:
Linux 3.13-rc8 (2014-01-12 17:04:18
On Sat, Feb 1, 2014 at 9:23 PM, Helge Deller del...@gmx.de wrote:
Hi Linus,
please pull the latest updates for the parisc architecture from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-for-3.14
The three major changes in this patchset is a implementation
.. which *does* actually bring up something that might work, and might
be a good idea: remove the restore math state or set TS from the
normal kernel paths *entirely*, and move it to the return to user
space phase.
This definitely seems much more sensible. For processors without
optimized
It would be good to know how often #3 happens on a real workload.
On February 1, 2014 1:17:10 PM PST, George Spelvin li...@horizon.com wrote:
.. which *does* actually bring up something that might work, and
might
be a good idea: remove the restore math state or set TS from the
normal kernel
Hi Heiko,
On Fri, Jan 31, 2014 at 11:03:03PM +0100, Heiko Stübner wrote:
On Monday, 20. January 2014 16:41:43 Heiko Stübner wrote:
This series enables the use of the additional cores on Rockchip
Cortex-A9 SoCs.
So, two weeks without any general complaints, but I guess part of the more
These bindings can be used to register Maxim ModelGauge ICs fuel gauge
(MAX17040/41/43/44/48/49/58/59)
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt | 61
++
1 file changed, 61
Remove Maxim MAX17040 gauge driver since it is superseded by full-functional
Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
drivers/power/Kconfig|8 -
drivers/power/Makefile
Hello.
This adds the folowing:
- Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
- Document DT bindings
- Remove superseded Maxim MAX17040 gauge driver
Vladimir Barinov (3):
[1/3] power_supply: modelgauge_battery: Maxim ModelGauge ICs gauge
[2/3] dt: Document
Add Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
Signed-off-by: Vladimir Barinov vladimir.bari...@cogentembedded.com
---
drivers/power/Kconfig|9
drivers/power/Makefile |1
From: Rob Herring r...@kernel.org
The addition of THERMAL and THERMAL_CPU selections causes a kconfig
warning on highbank platforms:
warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has
unmet direct dependencies (ARCH_HAS_CPUFREQ CPU_FREQ HAVE_CLK
REGULATOR OF THERMAL
Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot:
Add a clumsy-but-working FB support for GK20A. This chip only uses system
memory, so we allocate a big chunk using CMA and let the existing memory
managers work on it.
A better future design would be to allocate objects
On Fri, Jan 31, 2014 at 11:17:29AM +0100, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 05:03:48AM -0500, George Spelvin wrote:
How about getting rid of that TICKET_MSB mess and doing something like:
#define TICKET_MASK 0x
static inline void ticket_spin_unlock(atomic_t *tickets)
On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach d...@lynxeye.de wrote:
Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot:
Add a clumsy-but-working FB support for GK20A. This chip only uses system
memory, so we allocate a big chunk using CMA and let the existing memory
managers work
On 02/01/2014 01:17 PM, George Spelvin wrote:
.. which *does* actually bring up something that might work, and might
be a good idea: remove the restore math state or set TS from the
normal kernel paths *entirely*, and move it to the return to user
space phase.
This definitely seems much
On Sat, Feb 1, 2014 at 7:32 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
This patch move the vsyscall_gtod_data handling out of vsyscall_64.c
into an additonal file vsyscall_gtod.c to make the functionality
available for x86 32 bit kernel.
It also adds a new
On Sat, 1 Feb 2014, Petr Tesarik wrote:
With DISCONTIGMEM, the mapping between a pfn and its owning node is
initialized using data provided by the BIOS. However, the initialization
may fail if the extents are not aligned to section boundary (64M).
The symptom of this bug is an early boot
On Friday, January 31, 2014 06:34:22 PM Rafael J. Wysocki wrote:
On Friday, January 31, 2014 07:09:51 PM Mika Westerberg wrote:
On Fri, Jan 31, 2014 at 05:16:03PM +0100, Rafael J. Wysocki wrote:
[...]
[ 64.914639] ACPI: \_SB_.PCI0.RP05: ACPI_NOTIFY_BUS_CHECK event
[ 64.914640]
Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin:
On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach d...@lynxeye.de wrote:
Am Samstag, den 01.02.2014, 12:16 +0900 schrieb Alexandre Courbot:
Add a clumsy-but-working FB support for GK20A. This chip only uses system
memory, so we allocate
On Sat, Feb 1, 2014 at 7:32 AM, stef...@seibold.net wrote:
From: Stefani Seibold stef...@seibold.net
This patch add the time support for 32 bit a VDSO to a 32 bit kernel.
For 32 bit programs running on a 32 bit kernel, the same mechanism is
used as for 64 bit programs running on a 64 bit
On Thu, 30 Jan 2014, Chris Mason wrote:
Hi Linus
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
There are two conflicts right now, one with the ACL code (pick your
version) and one with Kent's changes in the block layer
On Sat, Feb 1, 2014 at 3:40 PM, H. Peter Anvin h...@zytor.com wrote:
OK, let's circle back for a bit. We have an active bug, and we clearly
have a lot of restructuring that could/should be done. We need to fix
the bug first; if we're going to a bunch of restructuring then that
ought to be
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
None of the existing users of struct acpi_dock_ops actually needs the
first argument of its member functions, so redefine those functions
to take only two arguments, the event type and data pointer, and
update the users of struct acpi_dock_ops
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking) modified ACPIPHP to protect its PCI device removal and addition
code paths from races against sysfs-driven rescan and remove operations
with the help of PCI
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After recent PCI core changes related to the rescan/remove locking,
the ACPIPHP's disable_slot() function is only called under the
general PCI rescan/remove lock, so it doesn't have to use
dev_in_slot() any more to avoid race conditions. Make it
On Monday, January 27, 2014 01:37:17 AM Rafael J. Wysocki wrote:
Hi All,
ACPIPHP can be simplified a bit on top of some PCI and ACPI changes merged
recently and the following series of patches implements those simplifications:
[1/11] Fix up two kerneldoc comments in acpiphp_glue.c.
[2/11]
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Add proper kerneldoc comments describing acpiphp_enumerate_slots()
and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/pci/hotplug/acpiphp_glue.c | 14 ++
1 file changed, 10
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
According to the changelog of commit 29ed1f29b68a (PCI: pciehp: Fix null
pointer deref when hot-removing SR-IOV device) it is unsafe to walk the
bus-devices list of a PCI bus and remove devices from it in direct order,
because that may lead to
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Make hotplug_event() use acpi_handle_debug() instead of an open-coded
debug message printing and clean up the messages printed by it.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/pci/hotplug/acpiphp_glue.c | 12
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
The err label in register_slot() is only jumped to from one place,
so move the code under the label to that place and drop the label.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/pci/hotplug/acpiphp_glue.c | 12
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
If trim_stale_devices() calls acpi_bus_trim() directly, we can
save a potentially costly acpi_bus_get_device() invocation. After
making that change acpiphp_bus_trim() would only be called from one
place, so move the code from it to that place
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After recent modifications of the ACPI core making it create a struct
acpi_device object for every namespace node representing a device
regardless of the current status of that device the ACPIPHP code
can store a struct acpi_device pointer
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
If a struct acpi_device pointer is passed to acpiphp_no_hotplug()
instead of an ACPI handle, the function won't need to call
acpi_bus_get_device(), which may be costly, any more. Then,
trim_stale_devices() can call acpiphp_no_hotplug() passing
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
After recent PCI core changes related to the rescan/remove locking,
the code sections under crit_sect mutexes from ACPIPHP slot objects
are always executed under the general PCI rescan/remove lock.
For this reason, the crit_sect mutexes are
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
acpiphp_bus_add() is only called from one place, so move the code out
of it into that place and drop it. Also make that code use
func_to_acpi_device() to get the struct acpi_device pointer it needs
instead of calling acpi_bus_get_device() which
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
A few lines of code can be cut from hotplug_event() by defining
and initializing the slot variable at the top of the function,
so do that.
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
drivers/pci/hotplug/acpiphp_glue.c | 19
201 - 300 of 368 matches
Mail list logo
