On Sat, 2014-02-01 at 17:06 -0800, Suresh Siddha wrote:
> Meanwhile I have the patch removing the delayed dynamic allocation for
> non-eager fpu. will post it after some testing.
Appended the patch for this. Tested for last 4-5 hours on my laptop.
The real fix for Nate's problem will be coming
On Sat, Feb 01, 2014 at 10:43:11AM -0800, Linus Torvalds wrote:
> On Fri, Jan 31, 2014 at 6:32 AM, Greg KH 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
On 01/31/14 16:24, Andrew Morton wrote:
On Wed, 29 Jan 2014 22:24:11 -0600 Rob Landley 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 (with the notably exception of
spi) indexes
Some very trivial comments below:
On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot wrote:
> Add support for initializing the priv ring of GK20A. This is done by the
> BIOS on desktop GPUs, but needs to be done by hand on Tegra.
>
> Signed-off-by: Alexandre Courbot
> ---
>
Commit-ID: 85fc73a2cdf10cf42bc36fb3bca3896b2095a1c2
Gitweb: http://git.kernel.org/tip/85fc73a2cdf10cf42bc36fb3bca3896b2095a1c2
Author: Petr Tesarik
AuthorDate: Sat, 1 Feb 2014 13:30:19 +0100
Committer: H. Peter Anvin
CommitDate: Sat, 1 Feb 2014 22:15:51 -0800
x86: Fix the
Commit-ID: 170750c108bb9382f32a2a99d097aa07d551a89e
Gitweb: http://git.kernel.org/tip/170750c108bb9382f32a2a99d097aa07d551a89e
Author: Petr Tesarik
AuthorDate: Sat, 1 Feb 2014 13:30:19 +0100
Committer: H. Peter Anvin
CommitDate: Sat, 1 Feb 2014 21:57:48 -0800
x86: Fix the
From: Namjae Jeon
Update FALLOC_FL_COLLAPSE_RANGE flag in fallocate.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
man2/fallocate.2 | 21 +
1 file changed, 21 insertions(+)
diff --git a/man2/fallocate.2 b/man2/fallocate.2
index ec9011c..69a4dbd 100644
From: Namjae Jeon
We execute collapse range multiple times on same file.
Each collapse range call collapses a single alternate block.
After the test execution, file will be left with 80 blocks and
as much number of extents.
We also check for file system consistency after the completion.
From: Namjae Jeon
This testcase(002) tries to test various corner cases with delayed extents
for fcollapse range functionality over different type of extents.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
tests/shared/002 | 65
Page migration will fail for memory that is pinned in memory with, for
example, get_user_pages(). In this case, it is unnecessary to take
zone->lru_lock or isolating the page and passing it to page migration
which will ultimately fail.
This is a racy check, the page can still change from under
From: Namjae Jeon
This testcase(004) tries to test various corner cases with delayed extents and
pre-existing holes for fcollapse range functionality
over different type of extents.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
tests/shared/004 | 65
From: Namjae Jeon
This testcase(003) tries to test various corner cases with pre-existing holes
for fcollapse range functionality over different type of extents.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
tests/shared/003 | 65
From: Namjae Jeon
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
Reviewed-by: Dave Chinner
---
io/prealloc.c | 41 +++--
man/man8/xfs_io.8 |6 ++
2 files changed, 45
From: Namjae Jeon
This testcase(001) tries to test various corner cases
for fcollapse range functionality over different type of extents.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
common/punch | 133 --
common/rc
From: Namjae Jeon
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
fs/xfs/xfs_bmap.c | 195
fs/xfs/xfs_bmap.h |5 ++
fs/xfs/xfs_bmap_util.c | 99
From: Namjae Jeon
Add support FALLOC_FL_COLLAPSE_RANGE for fallocate
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
fs/ext4/ext4.h |3 +
fs/ext4/extents.c | 297 ++-
fs/ext4/move_extent.c |2 +-
From: Namjae Jeon
Add new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate.
updated detailed semantics in comments.
Signed-off-by: Namjae Jeon
Signed-off-by: Ashish Sangwan
---
fs/open.c | 24 +---
include/uapi/linux/falloc.h | 21 +
From: Namjae Jeon
This patch series is in response of the following post:
http://lwn.net/Articles/556136/
"ext4: introduce two new ioctls"
Dave chinner suggested that truncate_block_range
(which was one of the ioctls name) should be an fallocate operation
and not any fs specific ioctl, hence we
hid-logitech-dj uses its own ->hidinput_input_event() instead of
the generic binding in hid-input.
Moving the handling of LEDs towards logi_dj_output_hidraw_report()
allows two things:
- remove hidinput_input_event in struct hid_device
- hidraw user space programs can also set the LEDs
Add output_report and raw_request to i2c-hid.
Hopefully, we will manage to have the same transport level between
all the transport drivers.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/i2c-hid/i2c-hid.c | 24
1 file changed, 24 insertions(+)
diff --git
Those callbacks are not mandatory, so it's better to add inliners
to use them safely.
Signed-off-by: Benjamin Tissoires
---
include/linux/hid.h | 45 +
1 file changed, 45 insertions(+)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index
- Move hidp_output_report() above
- Removed duplicated code in hidp_output_raw_report()
Signed-off-by: Benjamin Tissoires
---
net/bluetooth/hidp/core.c | 68 ---
1 file changed, 11 insertions(+), 57 deletions(-)
diff --git a/net/bluetooth/hidp/core.c
Hi guys,
This is an attempt to complete the branch for-3.15/ll-driver-new-callbacks:
- try to implement as much as possible ll_driver callbacks (some are still
missing, but I did not had the time to complete it)
- add inliners hid_hw_* for all the ll_driver callbacks
- remove transport
hidp uses its own ->hidinput_input_event() instead of the generic binding
in hid-input.
Moving the handling of LEDs towards hidp_hidinput_event() allows two things:
- remove hidinput_input_event definitively from struct hid_device
- hidraw user space programs can also set the LEDs
Signed-off-by:
dev->hid_get_raw_report(X) and hid_hw_raw_request(X, HID_REQ_GET_REPORT)
are strictly equivalent. Switch the hid subsystem to the hid_hw notation
and remove the field .hid_get_raw_report in struct hid_device.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 6 +++---
All the different transport drivers use now the generic event handling
in hid-input. We can remove the handler definitively now.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 4 +---
include/linux/hid.h | 4
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git
Well, no use to keep twice the same code.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/usbhid/hid-core.c | 64 ---
1 file changed, 11 insertions(+), 53 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index
struct hid_ll_driver is responsible for the transport communication.
Move hid_output_raw_report from hid_device to the transport layer then.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c| 2 +-
drivers/hid/hid-logitech-dj.c | 2 +-
drivers/hid/hid-sony.c | 11
Add a helper to access hdev->hid_output_raw_report().
To convert the drivers, use the following snippets:
for i in drivers/hid/*.c
do
sed -i.bak "s/[^ \t]*->hid_output_raw_report(/hid_output_raw_report(/g" $i
done
Then manually fix for checkpatch.pl
Signed-off-by: Benjamin Tissoires
---
It was missing, so adding it.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/uhid.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
index f5a2b19..438c9f1 100644
--- a/drivers/hid/uhid.c
+++ b/drivers/hid/uhid.c
@@ -270,6 +270,22
When using hid_output_report(), the buffer should be allocated by
hid_alloc_report_buf(),
not a custom malloc.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-input.c | 2 +-
drivers/hid/i2c-hid/i2c-hid.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
On Fri, 2014-01-31 at 15:34 +0100, Sebastian Andrzej Siewior wrote:
> irq_work is processed in softirq context on -RT because we want to avoid
> long latencies which might arise from processing lots of perf events.
> The noHZ-full mode requires its callback to be called from real hardirq
>
From: Shaibal Dutta
Allow the scheduler to select the best CPU to handle hub initalization
and LED blinking work. This extends idle residency times on idle CPUs
and conserves power.
This functionality is enabled when CONFIG_WQ_POWER_EFFICIENT is selected.
Cc: Greg Kroah-Hartman
Cc: Alan Stern
From: "H. Peter Anvin"
We have two APIs for compatiblity timespec/val, with confusingly
similar names. compat_(get|put)_time(val|spec) *do* handle the case
where COMPAT_USE_64BIT_TIME is set, whereas
(get|put)_compat_time(val|spec) do not. This is an accident waiting
to happen.
Clean it up by
On Sat, Feb 1, 2014 at 6:32 PM, Andy Lutomirski wrote:
> On a stock Fedora installation:
>
> $ sudo auditctl -l
> No rules
>
> Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and
> __audit_syscall_exit account for >20% of syscall overhead according to
> perf.
>
> This sucks.
(2014/02/01 21:17), Chen Gang wrote:
> When CONFIG_KRETPROBES disabled, cleanup_rp_inst() is useless too. It
> is only called by unregister_kretprobes() which is in CONFIG_KRETPROBES
> enabled area.
>
> The related warning (allmodconfig under avr32):
>
> kernel/kprobes.c:1181: warning:
On Sun, 2 Feb 2014, Filipe David Manana wrote:
> >> Btrfs: fix btrfs boot when compiled as built-in (+73/-9)
> >
> > This one, 14a958e678cd ("Btrfs: fix btrfs boot when compiled as
> > built-in"), breaks the build if CONFIG_LIBCRC32C=m:
> >
> > fs/built-in.o: In function
On a stock Fedora installation:
$ sudo auditctl -l
No rules
Nonetheless TIF_SYSCALL_AUDIT is set and the __audit_syscall_entry and
__audit_syscall_exit account for >20% of syscall overhead according to
perf.
This sucks. Unless I'm missing something, syscall auditing is *off*.
How hard would
Yes, that is exactly the "eageronly" features - currently LWP and MPX.
On February 1, 2014 6:05:05 PM PST, Linus Torvalds
wrote:
>On Sat, Feb 1, 2014 at 5:57 PM, H. Peter Anvin wrote:
>>
>> Twiddling CR0.TS is pretty slow if we're not taking advantage of it.
>
>Immaterial.
>
>We *already*
The current channel code is using scatterlist abstraction to pass data to the
ringbuffer API on the send path. This causes unnecessary translations
between virtual and physical addresses. Fix this.
Signed-off-by: K. Y. Srinivasan
---
drivers/hv/channel.c | 42
On Sat, Feb 1, 2014 at 5:57 PM, H. Peter Anvin wrote:
>
> Twiddling CR0.TS is pretty slow if we're not taking advantage of it.
Immaterial.
We *already* avoid twiddling TS if it's not needed.
It is true that we used to twiddle it at every context switch (and
then twiddle it *again* if we
On 02/01/2014 05:51 PM, Linus Torvalds wrote:
> On Sat, Feb 1, 2014 at 5:47 PM, Suresh Siddha wrote:
>>
>> So if the restore failed, we should do something like drop_init_fpu(),
>> which will restore init-state to the registers.
>>
>> for eager-fpu() paths we don't use clts() stts() etc.
>
>
On Sat, Feb 1, 2014 at 5:51 PM, Linus Torvalds
wrote:
> On Sat, Feb 1, 2014 at 5:47 PM, Suresh Siddha wrote:
>>
>> So if the restore failed, we should do something like drop_init_fpu(),
>> which will restore init-state to the registers.
>>
>> for eager-fpu() paths we don't use clts() stts()
On Sat, Feb 1, 2014 at 5:47 PM, Suresh Siddha wrote:
>
> So if the restore failed, we should do something like drop_init_fpu(),
> which will restore init-state to the registers.
>
> for eager-fpu() paths we don't use clts() stts() etc.
Uhhuh. Ok.
Why do we do that, btw? I think it would make
On Sat, Feb 1, 2014 at 5:38 PM, Linus Torvalds
wrote:
> It definitely does not want an else, I think.
>
> If tsk_used_math() is false, or if the FPU restore failed, we
> *definitely* need that stts(). Otherwise we'd return to user mode with
> random contents in the FP state, and let user mode
On Sat, Feb 1, 2014 at 5:43 PM, H. Peter Anvin wrote:
> What does the inner if clause do? It looks like it returns either way...
Suresh broke it with his suggested version.
The inner if-statement is supposed to avoid the stts *if* we had used
math *and* the FPU restore worked.
But with the
What does the inner if clause do? It looks like it returns either way...
On February 1, 2014 5:35:13 PM PST, Suresh Siddha wrote:
>On Sat, Feb 1, 2014 at 5:26 PM, H. Peter Anvin wrote:
>> Even "b" does that, no?
>
>oh right. It needs an else. only for non-eager fpu case we should do
>stts()
>
>
On Sat, Feb 1, 2014 at 5:35 PM, Suresh Siddha wrote:
> On Sat, Feb 1, 2014 at 5:26 PM, H. Peter Anvin wrote:
>> Even "b" does that, no?
>
> oh right. It needs an else. only for non-eager fpu case we should do stts()
It definitely does not want an else, I think.
If tsk_used_math() is false, or
On Sat, Feb 1, 2014 at 5:26 PM, H. Peter Anvin wrote:
> Even "b" does that, no?
oh right. It needs an else. only for non-eager fpu case we should do stts()
void __kernel_fpu_end(void)
{
if (use_eager_fpu()) {
struct task_struct *me = current;
On Sun, Feb 2, 2014 at 12:15 AM, David Rientjes wrote:
> 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
On 02/01/2014 05:06 PM, Suresh Siddha wrote:
>
> so I will Ack for option "b", as option "a" breaks the features which
> don't take into account cr0.TS.
>
Even "b" does that, no? "a" should be fine as long as we don't ever use
those features in the kernel, even under kernel_fpu_begin/end().
>
On 02/01/2014 05:19 PM, George Spelvin 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 separate. The
> 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 separate. The first bit is how we fix the immediate bug.
Well,
On Sat, Feb 1, 2014 at 11:27 AM, Linus Torvalds
wrote:
> That said, regardless of the allocation issue, I do think that it's
> stupid for kernel_fpu_{begin,end} to save the math state if
> "used_math" was not set. So I do think__kernel_fpu_end() as-s is
> buggy and stupid.
For eager_fpu case,
From: "K. Y. Srinivasan"
Date: Fri, 31 Jan 2014 08:24:38 -0800
> Some minor cleanup of the receive path. Get rid of unnecessary
> indirection as well as unnecessary re-establishment of state.
It is not appropriate to submit cleanups at this time.
Please wait until the net-next tree opens back
From: Max Filippov
Date: Fri, 31 Jan 2014 09:41:03 +0400
> Hello David, Ben, Florian and everybody,
>
> this series implements ethtool callbacks for the ethoc driver as was
> requested by Florian.
>
> Changes v1->v2:
> - fix {get,set}_settings return code in case there's no PHY;
> - fix
On 02/01/2014 04:41 PM, H. Peter Anvin wrote:
>>
>> Right. But there's some obscure ABI reason for CONFIG_COMPAT_VDSO,
>> and if this breaks it, then it's no good. From extremely vague
>> memory, there's some version of SuSE that breaks if the 32-bit vdso
>> moves. I have no idea what the bug
From: Rafael J. Wysocki
Since acpi_bus_notify() is executed on all notifications for all
devices anyway, rename acpi_hotplug_notify_cb() to acpi_system_notify()
and call it directly from acpi_bus_notify() instead of installing
notify handlers pointing to it for all hotplug devices.
This change
From: Rafael J. Wysocki
The ACPI-based PCI hotplug (ACPIPHP) code currently attaches its
hotplug context objects directly to ACPI namespace nodes representing
hotplug devices. However, after recent changes causing struct
acpi_device to be created for every namespace node representing a
device
From: Rafael J. Wysocki
Subsequent changes will require the ACPI core to acquire the lock
protecting the ACPIPHP hotplug contexts, so move the definition of
the lock to the core and change its name to be more generic.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c|
From: Rafael J. Wysocki
There is a slight possibility for the ACPI device object pointed to
by adev in acpi_hotplug_notify_cb() to become invalid between the
acpi_bus_get_device() that it comes from and the subsequent get_device().
Namely, if acpi_scan_drop_device() runs concurrently with
From: Rafael J. Wysocki
Since acpi_hotplug_notify_cb() does not use its data argument any
more, the second argument of acpi_install_hotplug_notify_handler()
can be dropped, so do that and update its callers accordingly.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c|
On Wednesday, January 29, 2014 12:57:06 AM Rafael J. Wysocki wrote:
> On Tuesday, January 28, 2014 11:10:30 PM Rafael J. Wysocki wrote:
> > Hi All,
> >
> > It looks like there's time for more adventurous stuff. :-)
> >
> > The following series is on top of the one I sent on Sunday:
> >
> >
From: Rafael J. Wysocki
To avoid the need to install a hotplug notify handler for each ACPI
namespace node representing a device and having a matching scan
handler, move the check whether or not the ejection of the given
device is enabled through its scan handler from acpi_hotplug_notify_cb()
to
Yes, that we can move, of course.
On February 1, 2014 4:30:17 PM PST, Andy Lutomirski wrote:
>On Sat, Feb 1, 2014 at 4:26 PM, H. Peter Anvin wrote:
>> On 02/01/2014 03:59 PM, Andy Lutomirski wrote:
>>>
>>> If it is, indeed, okay to use non-fixed maps on 32-bit, it might
>>> also be okay on
On Sat, Feb 1, 2014 at 4:26 PM, H. Peter Anvin wrote:
> On 02/01/2014 03:59 PM, Andy Lutomirski wrote:
>>
>> If it is, indeed, okay to use non-fixed maps on 32-bit, it might
>> also be okay on 64-bit. If so, it could be useful to implement that,
>> which would remove a bit of a wart and allow
On 02/01/2014 03:59 PM, Andy Lutomirski wrote:
>
> If it is, indeed, okay to use non-fixed maps on 32-bit, it might
> also be okay on 64-bit. If so, it could be useful to implement that,
> which would remove a bit of a wart and allow PR_SET_TSC to work
> usefully for 64-bit userspace. (This
Hi all,
while working with regulators, I noticed that there is no
devm_regulator_enable() API.
Seems to me it would be useful to have it, but then devm_clk_enable() doesn't
exist either,
so I wonder if there is a reason for not having it.
I'll be happy to submit a patch if people think it is
From: Rafael J. Wysocki
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
---
drivers/pci/hotplug/acpiphp_glue.c | 19 ++-
1 file changed, 6
From: Rafael J. Wysocki
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 may be costly.
From: Rafael J. Wysocki
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 simply redundant, so drop
them.
From: Rafael J. Wysocki
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
the struct acpi_device
From: Rafael J. Wysocki
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 instead of an ACPI handle
in
From: Rafael J. Wysocki
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 and drop it.
Signed-off-by:
From: Rafael J. Wysocki
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
---
drivers/pci/hotplug/acpiphp_glue.c | 12 +++-
1 file changed, 3 insertions(+), 9
From: Rafael J. Wysocki
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
---
drivers/pci/hotplug/acpiphp_glue.c | 12
1 file changed, 4 insertions(+), 8
From: Rafael J. Wysocki
Add proper kerneldoc comments describing acpiphp_enumerate_slots()
and acpiphp_remove_slots().
Signed-off-by: Rafael J. Wysocki
---
drivers/pci/hotplug/acpiphp_glue.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
Index:
From: Rafael J. Wysocki
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 NULL pointer dereferences
From: Rafael J. Wysocki
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 rescan-remove locking. However,
From: Rafael J. Wysocki
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 simply
walk the devices
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.
>
From: Rafael J. Wysocki
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 accordingly.
Signed-off-by:
On Sat, Feb 1, 2014 at 3:40 PM, H. Peter Anvin 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 separate.
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
On Sat, Feb 1, 2014 at 7:32 AM, wrote:
> From: Stefani Seibold
>
> 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
Am Samstag, den 01.02.2014, 18:28 -0500 schrieb Ilia Mirkin:
> On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach 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
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
> > [
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
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
On Sat, Feb 1, 2014 at 7:32 AM, wrote:
> From: Stefani Seibold
>
> 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
On Sat, Feb 1, 2014 at 8:40 AM, Lucas Stach 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 it.
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
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
From: Rob Herring
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 &&
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
---
drivers/power/Kconfig|8 -
drivers/power/Makefile |1
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
---
drivers/power/Kconfig|9
drivers/power/Makefile |1
drivers/power/modelgauge_battery.c | 838
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
---
Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt | 61
++
1 file changed, 61 insertions(+)
Index:
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
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 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
1 - 100 of 368 matches
Mail list logo
