>> Looks like the hlist change is probably the issue, though it specifically
>> uses:
>>
>> #define hlist_entry_safe(ptr, type, member) \
>> (ptr) ? hlist_entry(ptr, type, member) : NULL
>>
>> I'm still looking at the code in question and it's assembly, but I c
On mer., 2013-03-06 at 21:30 -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 04 Mar 2013, Borislav Petkov wrote:
> > I get this in dmesg with 3.9-rc1:
> >
> > [ 12.951434] thinkpad_acpi: unhandled HKEY event 0x6050
> > [ 12.951438] thinkpad_acpi: please report the conditions when this
> ev
On 03/08/2013 02:30 PM, Daniel Mack wrote:
On 08.03.2013 03:15, Mark Brown wrote:
On Thu, Mar 07, 2013 at 11:31:59PM +0100, Daniel Mack wrote:
On 07.03.2013 19:42, Afzal Mohammed wrote:
Grep'ing through arch/arm, it seems that the imx arch does the same
thing my patch does, but I could also ima
* Frederic Weisbecker wrote:
> Hi,
>
> Several fixes there. And this version should have much lesser spurious
> warnings.
> Your testing and reviews is very appreciated.
>
> The 5 first patches of the series are pending on a pull request for -tip
> (3.10
> material).
>
> I'm now consideri
Dave Jones writes:
> On Fri, Mar 08, 2013 at 07:38:33PM -0800, Eric W. Biederman wrote:
> > Dave Jones writes:
> >
> > > On Fri, Mar 08, 2013 at 07:16:09PM -0800, Linus Torvalds wrote:
> > > > Goodie. Your bug reports gave me heartburn. But it sounds like we
> have an
> > > > angle on a
Rakib Mullick writes:
> On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman
> wrote:
>>
>> When a new task is created one of two things needs to happen.
>> A) A reference count needs to be added to the current nsproxy.
>> B) B a new nsproxy needs to be created.
>>
>> The way that code works today
On 03/08/2013 04:58 PM, David Woodhouse wrote:
I'm just looking through the kernel for krealloc() abuse, and the
'interesting' code in mvebu_pinctrl_build_functions() came to my
attention.
First it allocates an array 'funcs' as follows:
/* we allocate functions for number of pins and hop
Commit 9259826ccb8165f797e4c2c9d17925b41af5f6ae ("res_counter: remove
include of cgroup.h from res_counter.h") removed the indirect inclusion of
, breaking the build on m68k and sparc:
In file included from mm/memcontrol.c:29:
include/linux/res_counter.h: In function ‘res_counter_set_limit’:
inclu
Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
> On Fri, 8 Mar 2013, Peter Hurley wrote:
>
> > [ +linux-usb ]
> >
> > On Fri, 2013-03-08 at 14:12 -0500, Shawn Starr wrote:
> > > Hello folks,
> > >
> > > I am noticing since rc0 and now rc1, very poor interrupt handling.
> > > Keyboa
On 03/09/2013 12:44 AM, Josh Boyer wrote:
> On Fri, Mar 08, 2013 at 06:28:09PM -0500, Josh Boyer wrote:
>> On Sat, Mar 09, 2013 at 12:14:23AM +0100, Jiri Slaby wrote:
>>> On 03/09/2013 12:10 AM, Jiri Slaby wrote:
On 03/08/2013 11:58 PM, Jiri Slaby wrote:
> On 03/08/2013 11:49 PM, Josh Boye
Hi Bjorn,
On 03/08/13 22:57, Bjorn Helgaas wrote:
[+cc Rafael, in case the _OSC thing rings a bell with him]
On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton wrote:
On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton
wrote:
On 03/07/13 17:30, Bjorn Helgaas wr
From: Matwey V. Kornilov
This patch adds support for the Lake Shore Cryotronics devices to
the CP210x driver.
Signed-off-by: Matwey V. Kornilov
---
These lines are ported from cp210x driver distributed by Lake Shore web site:
http://www.lakeshore.com/Documents/Lake%20Shore%20cp210x-3.0.0.tar
On 2013/3/9 16:51, Geert Uytterhoeven wrote:
> Commit 9259826ccb8165f797e4c2c9d17925b41af5f6ae ("res_counter: remove
> include of cgroup.h from res_counter.h") removed the indirect inclusion of
> , breaking the build on m68k and sparc:
>
> In file included from mm/memcontrol.c:29:
> include/linux/
On 7 March 2013 12:13, Amit Daniel Kachhap wrote:
> diff --git a/drivers/cpufreq/exynos5440-cpufreq.c
> b/drivers/cpufreq/exynos5440-cpufreq.c
> +struct exynos_dvfs_data {
> + void __iomem *base;
> + struct resource *mem;
> + int irq;
> + struct clk *cpu_clk;
> + uns
On Sat, Mar 09, 2013 at 09:06:46AM +0100, Yves-Alexis Perez wrote:
> Also see https://bugzilla.kernel.org/show_bug.cgi?id=51231 and
> https://patchwork.kernel.org/patch/2124861/
Great, another fit-the-hardware-to-the-software idiocy because those
dimwits which call their pile of stinking software
On 08-03-13 23:59, Shuah Khan wrote:
:
Should this be tagged for stables releases? This patch went into suse
git and just checking to see if it should go into stable releases.
Hello,
This patch will make the module automatically load on some new HP
laptops. So although it's not fixing a bug, it
On 02/28/2013 11:24 AM, Maarten Lankhorst wrote:
> This will allow me to call functions that have multiple arguments if fastpath
> fails.
> This is required to support ticket mutexes, because they need to be able to
> pass an
> extra argument to the fail function.
>
> Originally I duplicated the
On Friday 01 February 2013 22:44:55 Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 07:23:52 PM Peter Wu wrote:
> > On Thursday 31 January 2013 23:32:40 Rafael J. Wysocki wrote:
> > > In general, for ACPI device power management to work, the initial
> > > power states of devices must be kno
[ +linux-pci, +linux-acpi, +Rafael Wysocki, +Bjorn Helgaas ]
On Sat, 2013-03-09 at 09:53 +0100, Thomas Meyer wrote:
> Am Freitag, den 08.03.2013, 21:19 -0500 schrieb Alan Stern:
> > On Fri, 8 Mar 2013, Peter Hurley wrote:
> >
> > > [ +linux-usb ]
> > >
> > > On Fri, 2013-03-08 at 14:12 -0500, Sh
Hello,
while with older kernels, I could go down to a power drain of 8 Watt at
minimum display intensity, booting to Opensuse 3.8.2-2-vanilla and other
recent kernels, I can no longer get below 16 Watt.
Has anybody seen something similar? Any hints?
Thanks
--
Uwe Bonnesb...@elek
Hello,
looking for a possible reason for the higher power drain of recent kernels,
as reported in a recent post, I did on my Thinkpad T520 with Opensuse 12.2
and kernel-of-the-day 3.8.2-2-vanilla with
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [Quadro NVS4200M]
(rev a1)
> echo O
On Sat, Mar 09, 2013 at 10:14:14AM +0100, Jiri Slaby wrote:
> On 03/09/2013 12:44 AM, Josh Boyer wrote:
> > On Fri, Mar 08, 2013 at 06:28:09PM -0500, Josh Boyer wrote:
> >> On Sat, Mar 09, 2013 at 12:14:23AM +0100, Jiri Slaby wrote:
> >>> On 03/09/2013 12:10 AM, Jiri Slaby wrote:
> On 03/08/20
On Sat, Mar 9, 2013 at 4:41 AM, Greg KH wrote:
> On Fri, Mar 08, 2013 at 09:35:17PM +0200, Tommi Rantala wrote:
>> Hello,
>>
>> Saw this while fuzzing with trinity:
>>
>> # ./trinity -q -l off -C20 --dangerous -c ioctl -V /dev
>> Trinity v1.2pre Dave Jones
>> [3450] Marking 64-bit syscall 16 (io
On Fri, Mar 08, 2013 at 09:59:49PM -0500, Dave Jones wrote:
> restarted my nfs server, and mounted it from a Mac, and got this..
>
>
> [47433.585266] WARNING: at lib/debugobjects.c:260
> debug_print_object+0x8c/0xb0()
Thanks for the report. It's a known issue. I'd like Trond to either
take th
On 03/09/2013 02:30 PM, Josh Boyer wrote:
> From: Josh Boyer
> Date: Fri, 8 Mar 2013 21:13:52 -0500
> Subject: [PATCH] serial: 8250: Keep 8250. module options functional
> after driver rename
>
> With commit 835d844d1 (8250_pnp: do pnp probe before legacy probe), the
> 8250 driver was renamed to
Namjae Jeon writes:
> static int fat_file_release(struct inode *inode, struct file *filp)
> {
> + struct super_block *sb = inode->i_sb;
> + loff_t mmu_private_ideal = (inode->i_size + (sb->s_blocksize-1)) &
> + ~(sb->s_blocksize-1);
> + if (mmu_privat
> -Original Message-
> From: J. Bruce Fields [mailto:bfie...@fieldses.org]
> Sent: Saturday, March 09, 2013 9:01 AM
> To: Dave Jones; Linux Kernel; linux-...@vger.kernel.org; Myklebust, Trond
> Subject: Re: sunrpc ODEBUG assertion.
>
> On Fri, Mar 08, 2013 at 09:59:49PM -0500, Dave Jones w
Hi, Bjorn
>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
>> >> > BAR4, system will hang after executing lspci command
>> >>
>> >> This needs more explanation. We've already read the BARs by the
>> >> time header quirks are run, so apparently it's not just the mere
>>
Generally, both atomic_inc_unless_negative() and
atomic_dec_unless_positive() need at least two atomic_cmpxchg()
to complete the atomic operation. In fact, the 1st atomic_cmpxchg()
is just used to read current value of the atomic variable at most times.
Considered memory barrier, bus lock, cache w
On Thu, Mar 07, 2013 at 11:02:13AM -0300, Mauro Carvalho Chehab wrote:
> Sure. See below:
>
> [ 19.062902] EDAC MC: Ver: 3.0.0
> [ 19.088757] EDAC DEBUG: edac_mc_sysfs_init: device mc created
> [ 19.284745] AMD64 EDAC driver v3.4.0
> [ 19.299082] EDAC amd64: DRAM ECC enabled.
> [ 19.3159
On Fri, Mar 8, 2013 at 8:18 PM, Anton Vorontsov wrote:
> Hi Paul,
>
> On Fri, Mar 08, 2013 at 11:38:41AM -0500, Paul Gortmaker wrote:
>> > I see. In that case, please feel free to send the patch to akpm with my
>> > Nack and pointing to this discussion. If Andrew agrees and I was wrong
>> > (and I
The Kconfig entry for SUNRPC_SWAP selects NETVM. That select statement
was added in commit a564b8f0398636ba30b07c0eaebdef7ff7837249 ("nfs:
enable swap on NFS"). But there's no Kconfig symbol NETVM. It apparently
was only in used in development versions of the swap over nfs
functionality but never e
The Kconfig entry for DA9055 PMIC Support selects PMIC_DA9055. That was
probably inspired by the similar select statement in the entry for
DA9052/53 PMIC with I2C. But the DA9055 PMIC only comes in an I2C
variant and its driver doesn't need a separate Kconfig symbol for shared
code. In any case, th
Device stucks on filesystem writes, unless following quirk is passed:
echo 04e8:5136:m > /sys/module/usb_storage/parameters/quirks
Add corresponding entry to unusual_devs.h
Signed-off-by: Dmitry Artamonow
---
drivers/usb/storage/unusual_devs.h |7 +++
1 files changed, 7 insertions(+),
2013/3/9 Ming Lei :
> On Sat, Mar 9, 2013 at 4:41 AM, Greg KH wrote:
>> On Fri, Mar 08, 2013 at 09:35:17PM +0200, Tommi Rantala wrote:
>>> Hello,
>>>
>>> Saw this while fuzzing with trinity:
>>>
>>> # ./trinity -q -l off -C20 --dangerous -c ioctl -V /dev
>>> Trinity v1.2pre Dave Jones
>>> [3450]
On Sat, Mar 9, 2013 at 2:33 PM, Eric W. Biederman wrote:
> Rakib Mullick writes:
>
>> On Fri, Mar 8, 2013 at 10:01 PM, Eric W. Biederman
>> wrote:
>>>
>>> When a new task is created one of two things needs to happen.
>>> A) A reference count needs to be added to the current nsproxy.
>>> B) B a n
On Saturday 09 March 2013, Paul Gortmaker wrote:
I'd Cc: Paul's whole list, but it would bounce, so I'll post this where it
will be seen.
>On Fri, Mar 8, 2013 at 8:18 PM, Anton Vorontsov wrote:
>> Hi Paul,
>>
>> On Fri, Mar 08, 2013 at 11:38:41AM -0500, Paul Gortmaker wrote:
>>> > I see. In th
[1.] rtl8192cu driver issue with Kernel version 3.7.5 and 3.7.10
(archlinux)
[2.] Since last update (Kernel 3.7.5) the rtl8192cu driver does not work
properly (only tested with Kernel 3.7.5 and 3.7.10).
Although the hardware is correctly recognized and modules are load
(rtlwifi, rtl8192cu, rtl
On Sat, Mar 09, 2013 at 03:14:18PM +0100, Jiri Slaby wrote:
> On 03/09/2013 02:30 PM, Josh Boyer wrote:
> > From: Josh Boyer
> > Date: Fri, 8 Mar 2013 21:13:52 -0500
> > Subject: [PATCH] serial: 8250: Keep 8250. module options functional
> > after driver rename
> >
> > With commit 835d844d1 (825
Hi *,
same problem here on my HP Compaq 6910p.
I just tested with vanilla linux 3.8.2 -- unfortunately the problem
still persists.[1][2] The last (stable) kernel working for me is 3.6.11.
I'll happily provide any additional information which might help getting
this fixed. Just ask... :)
Pleas
ACK.
On Sat, Mar 09, 2013 at 05:02:31PM +0100, Paul Bolle wrote:
> The Kconfig entry for SUNRPC_SWAP selects NETVM. That select statement
> was added in commit a564b8f0398636ba30b07c0eaebdef7ff7837249 ("nfs:
> enable swap on NFS").
Cc'ing Mel Gorman just in case there was something else going on
On Tue, Mar 05, 2013 at 11:16:48PM +0100, Arnd Bergmann wrote:
> The OMAP IOMMU driver intentionally fails to build on OMAP1
> platforms, so we should not allow enabling it there.
>
> Signed-off-by: Arnd Bergmann
> Cc: Joerg Roedel
> Cc: io...@lists.linux-foundation.org
> Cc: Ohad Ben-Cohen
> C
On Tue, Feb 26, 2013 at 04:12:05PM +0100, Nikola Pajkovsky wrote:
> commit 318fe78 ("IOMMU, AMD Family15h Model10-1Fh erratum 746 Workaround")
> added amd_iommu_erratum_746_workaround and it's marked as __init, which is
> wrong
>
> WARNING: drivers/iommu/built-in.o(.text+0x639c): Section mismatch
On Fri, Mar 8, 2013 at 9:39 PM, Dan Carpenter wrote:
> On Fri, Mar 08, 2013 at 04:29:22PM -0800, Andrew Morton wrote:
>> Roughly how many instances of this are there kernel-wide?
>>
>
> Around 150 on x86 allmodconfig. They are pretty well audited.
I saw 207 on x86-64 allmodconfig. See the list t
The CONFIG_PM doesn't actually enable any of the PM callbacks, it
only allows to enable CONFIG_PM_SLEEP and CONFIG_PM_RUNTIME.
This means if CONFIG_PM is used to protect system sleep callbacks
then it may end up unreferenced if only runtime PM is enabled.
Hence protecting sleep callbacks with CONFI
When watching the irq name of tegra rtc, it shows as "rtc alarm"
which actually does not reflect the name related to driver.
Passing the device name to have the irq names with driver name.
Signed-off-by: Laxman Dewangan
---
drivers/rtc/rtc-tegra.c |2 +-
1 files changed, 1 insertions(+), 1
Make the Tegra RTC controller driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Laxman Dewangan
---
drivers/rtc/rtc-tegra.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
Use macro module_platform_driver_probe() to reduce some of the
boilerplate code in the driver.
Signed-off-by: Laxman Dewangan
---
drivers/rtc/rtc-tegra.c | 12 +---
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/rtc/rtc-tegra.c b/drivers/rtc/rtc-tegra.c
index f
This patch series does the cleanups in the rtc driver as follows:
- Protect suspend/resume with CONFIG_PM_SLEEP.
- Use dev_pm_ops in place of legacy way for suspend/resume.
- Properly reflect teh irq name when doing cat /proc/interrupts.
- Use module_platform_probe() to remove boilerplate code.
- u
NVIDIA's Tegra114 has 32 channels APB DMA controller. Add DT entry for
APB DMA controllers and make it compatible with "nvidia,tegra114-apbdma".
Tegra114 DMA controller is not compatible with Tegra30/Tegra20 DMA
controller driver as in T114, the global pause also clock gate the
DMA register and he
This patch series add DT entry for APB DMA, I2C, UART, KBC and SPI.
This patch series is generated on top of CCF work for T114 done by Peter
and hence it should be applied on top of T114 CCF patches.
Changes from V1:
- Add reeason why APBDMA is not compatible with older driver
in description.
-
NVIDIA's Tegra114 SoCs have the matrix keyboard controller which
supports 11x8 type of matrix. The number of rows and columns
are configurable.
Add DT entry for KBC controller with compatibility as "nvidia,tegra114-kbc",
"nvidia,tegra20-kbc".
Signed-off-by: Laxman Dewangan
---
Changes from V1:
-
NVIDIA's Tegra114 has 6 spi controllers. These controllers are
redesign on T114 with different register interface.
Add DT entry for spi controllers and make it compatible with
"nvidia,tegra114-spi".
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- None
arch/arm/boot/dts/tegra114.dtsi |
Add APB DMA requestor and serial aliases for serial controller.
There will be two serial driver i.e. 8250 based simple serial driver
and APB DMA based serial driver for higher baudrate and performace.
The simple serial driver get enabled with compatible "nvidia,tegra114-uart",
"nvidia,tegra20-uart
NVIDIA's Tegra114 has 5 i2c controllers. These controllers have
additional feature/configurations to make it functional over
Tegra30's i2c controller driver.
Add DT entry for i2c controllers and make it compatible with
"nvidia,tegra114-i2c".
Signed-off-by: Laxman Dewangan
---
Changes from V1:
-
i2c_del_mux_adapter() always returns 0. So all checks testing whether it will be
non zero will always evaluate to false and the conditional code is dead code.
This patch updates all callers of i2c_del_mux_adapter() to ignore its return
value and assume that it will always succeed (which it will). A
Currently i2c_del_adapter() returns -EINVAL when it gets an adapter which is not
registered. But none of the users of i2c_del_adapter() depend on this behavior,
so for the sake of being able to sanitize the return type of i2c_del_adapter
argue, that the purpose of i2c_del_adapter() is to remove an
i2c_del_mux_adapter always returns 0 and none of it current users check its
return value anyway. It is also an essential requirement of the Linux device
driver model, that functions which may be called from a device's remove callback
to free resources provided by the device, are not allowed to fail
Use devm_rtc_device_register for registering rtc device.
This will reduce the code for unregistering rtc device in
cleanup path and remove the implementation of remove
callback of platform driver.
Signed-off-by: Laxman Dewangan
---
drivers/rtc/rtc-tegra.c | 27 ---
1 fi
The detach_adapter callback has been deprecated for quite some time and has no
user left. Keeping it alive blocks other cleanups, so remove it.
Signed-off-by: Lars-Peter Clausen
---
drivers/i2c/i2c-core.c | 33 ++---
include/linux/i2c.h| 7 ++-
2 files change
i2c_del_adapter() is usually called from a drivers remove callback. The Linux
device driver model does not allow the remove callback to fail and all resources
allocated in the probe callback need to be freed, as well as all resources which
have been provided to the rest of the kernel(for example a
Hi Magnus,
Thank you for the patch.
On Tuesday 05 March 2013 09:32:19 Magnus Damm wrote:
> From: Magnus Damm
>
> This patch implements a GPIO driver for the R-Car series
> of SoCs from Renesas. This driver is designed to be reusable
> between multiple SoCs that share the same basic building blo
Currently i2c_del_adapter() returns 0 on success and potentially an error code
on failure. Unfortunately this doesn't mix too well with the Linux device driver
model. An i2c_adapter is usually registered in a drivers probe callback and
removed in the drivers remove callback. The Linux device driver
i2c_del_adapter() always returns 0. So all checks testing whether it will be
non zero will always evaluate to false and the conditional code is dead code.
This patch updates all callers of i2c_del_mux_adapter() to ignore the return
value and assume that it will always succeed (which it will). In a
Hi Michel,
Well. I can't say I really like this. 4/5 itself looks fine, but other
complications do not look nice, at least in the long term. Imho, imho,
I can be wrong.
Everyone seem to agree that tasklist should die, this series doesn't
even try to solve the fundamental problems with this global
On Sat, Mar 09, 2013 at 04:01:41PM +0800, Li Zefan wrote:
[ . . . ]
> >> hlist_first_rcu() doesn't have any side-effects, it doesn't modify the
> >> list whatsoever,
> >> so the only thing that can change is 'head'. Why is it allowed to change
> >> if the list
> >> is protected by RCU?
> >
> >
The error in lis3lv02_poweron() is harmless in the resume path, so
we should ignore it. It is inline with the other usages of lis3lv02_poweron()
and matches the 3.0 code for this routine. This patch is in suse git and
might have missed making it into the mainline.
opensuse - commit id: 66ccdac87c32
Hi,
There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce
FX 5200 Ultra). This happens also with current mainline kernel HEAD
(0aefda3e8188ad71168bd32152d41b3d72f04087).
git bisect tells the first bad commit is
1d7c71a3e2f77336df536855b0efd2dc5bdeb41b (drm/nouveau/disp: port v
On 03/08, Mandeep Singh Baines wrote:
>
> On Fri, Mar 8, 2013 at 9:59 AM, Oleg Nesterov wrote:
> > By discussion with Mandeep Singh Baines .
> >
> > Change dump_write(), dump_seek() and do_coredump() to check
> > signal_pending() and abort if it is true.
> >
> > We add the new trivial helper, dump
On Sat, 2013-03-09 at 09:49 +0100, Sebastian Hesselbarth wrote:
> I don't have a strong opinion on that, but I prefer not to have the list
> statically in the SoC specific drivers. I think counting the number of
> unique functions for each SoC specific driver once and verify the above
> heuristic (
The Kconfig entry for the Openmoko GTA02 / Freerunner phone selects
MACH_NEO1973. But there is no Kconfig symbol MACH_NEO1973. The select
statement for that symbol is a nop. It can safely be dropped.
Signed-off-by: Paul Bolle
---
0) Tested with "git grep".
1) There appear to be repositories that
On Thu, Mar 07, 2013 at 08:57:28AM -0800, Eric Dumazet wrote:
>
> Well, remove all alien patches and try to reproduce the bug with a
> pristine linux kernel.
I wrote to Spender (developer grsec) and he confirmed that it's possible
that a problem is with grsec patch.
Thank you greatly for your an
On 03/08, Andrew Morton wrote:
>
> On Fri, 8 Mar 2013 18:59:15 +0100 Oleg Nesterov wrote:
>
> > Change dump_write(), dump_seek() and do_coredump() to check
> > signal_pending() and abort if it is true.
>
> hm, why.
Firstly. we need these changes to ensure that the coredump won't delay
suspend, an
In Linus' current tree, the first time the command "make kernelrelease"
is run after building a kernel, the output contains some unwanted text.
Subsequent uses of the command produce the expected output. This appears
to be a regression - 3.8.2 does not have this problem.
This is easily demonst
David,
I will not be able to test before mid-week ealiest. I added Andrew Lunn to
the list. He and Thomas can test your patch for Kirkwood and Armada XP/370
respectively. I will test on Dove asap.
Sebastian
On Sat, Mar 9, 2013 at 8:02 PM, David Woodhouse wrote:
> On Sat, 2013-03-09 at 09:49 +01
On Sat, 2013-03-09 at 00:01 +, Russell King - ARM Linux wrote:
> It's actually quite clever. There's two levels to it.
>
> The first is that CONFIG_MACH_xxx result in their machine_is_xxx() macros
> being defined to constant zero if the CONFIG option is not enabled. That
> allows the compile
On 03/09, Li Zefan wrote:
>
> We don't need both patches for 3.9, so we'll queue Oleg's fix for 3.9 and
> yours for 3.10?
Well. OK, please see 1/1 (compile tested only).
But I still like the patch from Tejun more... Except _perhaps_ my
patch is better for 3.9 just because it is simpler.
And. I s
threadgroup_lock() takes signal->cred_guard_mutex to ensure that
thread_group_leader() is stable. This doesn't look nice, the scope
of this lock in do_execve() is huge.
And as Dave pointed out this can lead to deadlock, we have the
following dependencies:
do_execve: cred_guar
On Sat, Mar 9, 2013 at 12:01 PM, Oleg Nesterov wrote:
> threadgroup_lock() takes signal->cred_guard_mutex to ensure that
> thread_group_leader() is stable. This doesn't look nice, the scope
> of this lock in do_execve() is huge.
>
> And as Dave pointed out this can lead to deadlock, we have the
>
On 03/08, Lucas De Marchi wrote:
>
> Commit "7ff6764 usermodehelper: cleanup/fix __orderly_poweroff() &&
> argv_free()" simplified __orderly_poweroff() removing the need to use
> call_usermodehelper_fns().
>
> Since we are not passing any callback, it's simpler to use
> call_usermodehelper().
>
> S
On 03/08, Lucas De Marchi wrote:
>
> call_usermodehelper_setup() + call_usermodehelper_exec() need to be
> called instead of call_usermodehelper_fns() when the cleanup function
> needs to be called even when an ENOMEM error occurs. In this case using
> call_usermodehelper_fns() the user can't disti
On 03/08, Lucas De Marchi wrote:
>
> Use call_usermodehelper_setup() + call_usermodehelper_exec() instead of
> calling call_usermodehelper_fns(). In case the latter returns -ENOMEM
> the cleanup function may had not been called - in this case we would
> not free argv and module_name.
>
> Signed-off
On 03/08, Lucas De Marchi wrote:
>
> static int call_usermodehelper_keys(char *path, char **argv, char **envp,
> struct key *session_keyring, int wait)
> {
> - return call_usermodehelper_fns(path, argv, envp, wait,
> -u
On 03/08, Lucas De Marchi wrote:
>
> @@ -571,9 +572,17 @@ void do_coredump(siginfo_t *siginfo)
> goto fail_dropcount;
> }
>
> - retval = call_usermodehelper_fns(helper_argv[0], helper_argv,
> - NULL, UMH_WAIT_EXEC,
On Sat, 09 Mar 2013, Borislav Petkov wrote:
> On Sat, Mar 09, 2013 at 09:06:46AM +0100, Yves-Alexis Perez wrote:
> > Also see https://bugzilla.kernel.org/show_bug.cgi?id=51231 and
> > https://patchwork.kernel.org/patch/2124861/
>
> Great, another fit-the-hardware-to-the-software idiocy because tho
On Mon, Mar 04, 2013 at 02:04:19PM -0500, Neil Horman wrote:
> A few years back intel published a spec update:
> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>
> For the 5520 and 5500 chipsets which contained an errata (specificially
From: Joe Perches
Date: Fri, 8 Mar 2013 17:03:25 -0800
> Emitting netdev_alloc_skb and netdev_alloc_skb_ip_align OOM
> messages is unnecessary as there is already a dump_stack
> after allocation failures.
>
> Other trivial changes around these removals:
>
> Convert a few comparisons of pointer
Signed-off-by: Paul Bolle
---
Untested! This specifically needs testing on (some) 64 bit platforms,
because this means HAVE_ALIGNED_STRUCT_PAGE will not be selected anymore
on those platforms.
drivers/staging/zcache/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driv
On Thu, 07 Mar 2013, Mandeep Singh Baines wrote:
> On Thu, Mar 7, 2013 at 9:53 AM, Oleg Nesterov wrote:
> > hotkey_kthread() does try_to_freeze() under hotkey_thread_mutex.
> >
> > We can simply kill this mutex, hotkey_poll_stop_sync() does not need
> > to serialize with hotkey_kthread(). When kth
On Thu, 07 Mar 2013, Toshi Kani wrote:
> dock.0 on your Lenovo likely shows as "battery_bay", which I think you
> cannot undock regardless of this patch. Can you try to undock the one
You're supposed to be able to undock any thinkpad battery just fine, and it
used to work on older firmware such a
On 2013-02-22 03:03, Mantas Mikulėnas wrote:
> On 2013-02-22 01:54, Dave Airlie wrote:
>>>
>>> | radeon :01:00.0: No connectors reported connected with modes
>>> | [drm] Cannot find any crtc or sizes - going 1024x768
>>>
>>> The connector is definitely connected, since this is a laptop with a
>
On Sat, Mar 09, 2013 at 10:49:08AM -0500, Paul Gortmaker wrote:
[...]
> >> I didn't send the patch to akpm, but I did have a chance to ask akpm how
> >> dependencies should be used, and you can see his answer here:
> >>
> >> https://lkml.org/lkml/2013/3/7/456
> >
> > Thanks for asking! FWIW,
On Sat, Mar 09, 2013 at 05:49:13PM -0300, Henrique de Moraes Holschuh wrote:
> Hmm, I don't follow. thinkpad-acpi does run on ring 0, so was that aimed at
> me?
Huh, is "thinkpad-acpi" the name of a part of a house? :-)
> Or are you complaining about the Win-8 bug-to-bug compatibility madness
>
This could have been either ARCH_S5P64X0 or CPU_S5P6450. Looking at
commit 2555e663b367b8d555e76023f4de3f6338c28d6c ("ARM: S5P64X0: Add UART
serial support for S5P6450") - which added this typo - makes clear this
should be CPU_S5P6450.
Signed-off-by: Paul Bolle
---
Bravely untested.
drivers/tty
On Sat, Mar 9, 2013 at 1:49 PM, Neil Horman wrote:
> On Mon, Mar 04, 2013 at 02:04:19PM -0500, Neil Horman wrote:
>> A few years back intel published a spec update:
>> http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
>>
>> For the 5520 an
On Sat, Mar 09, 2013 at 10:10:08AM -0800, Christopher Li wrote:
> On Fri, Mar 8, 2013 at 9:39 PM, Dan Carpenter
> wrote:
> > On Fri, Mar 08, 2013 at 04:29:22PM -0800, Andrew Morton wrote:
> >> Roughly how many instances of this are there kernel-wide?
> >>
> >
> > Around 150 on x86 allmodconfig.
On Sat, Mar 09, 2013 at 07:02:05PM +, David Woodhouse wrote:
> On Sat, 2013-03-09 at 09:49 +0100, Sebastian Hesselbarth wrote:
> > I don't have a strong opinion on that, but I prefer not to have the list
> > statically in the SoC specific drivers. I think counting the number of
> > unique funct
On Sat, Mar 9, 2013 at 2:34 PM, Dan Carpenter wrote:
> The problems is if we go over the 8k stack. So big arrays are bad.
> Also if the dynamically sized array is inside a loop then normally
> GCC frees it after each iteration, but on some arches it didn't free
> it until after the last iteration
On Sat, Mar 9, 2013 at 7:49 AM, Xiangliang Yu wrote:
> Hi, Bjorn
>
>>> >> > Fix system hang issue: if first accessed resource file of BAR0 ~
>>> >> > BAR4, system will hang after executing lspci command
>>> >>
>>> >> This needs more explanation. We've already read the BARs by the
>>> >> time head
On Sat, 2013-03-09 at 17:53 -0500, Jason Cooper wrote:
> > + if (!nr_funcs)
>
> shouldn't this be:
>
> if (nr_funcs <= 0)
Hm, no. But the loop should terminate if nr_funcs ever reaches zero,
otherwise funcs->num_groups will be off the end of the original array:
diff --git a/drivers/
1 - 100 of 171 matches
Mail list logo
