Hi,
on my system (based on 2.6.16.17), i am trying to clear the cached
memory but it is not being cleared.
mars# free -m
total used free sharedbuffers cached
Mem: 925459465 0 0231
-/+ buffers/cache:22
* Mike Galbraith wrote:
> On Tue, 2014-12-02 at 08:33 -0800, Linus Torvalds wrote:
>
> > Looking again at that patch (the commit message still doesn't strike
> > me as wonderfully explanatory :^) makes me worry, though.
> >
> > Is that
> >
> > if (rq->skip_clock_update-- > 0)
> >
* Linus Torvalds wrote:
> On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
>
> >
> > Something that's still making me wonder if it's some kind of
> > hardware problem is the non-deterministic nature of this bug.
>
> I'd expect it to be a race condition, though. Which can easily
> cause th
If the freeing page and its buddy page are not at the same zone, the current
holding zone->lock for the freeing page cann't prevent buddy page getting
allocated, this could trigger VM_BUG_ON_PAGE in page_is_buddy() at a
very tiny chance, such as:
cpu 0: cpu
* Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
> >
> > >
> > > Something that's still making me wonder if it's some kind of
> > > hardware problem is the non-deterministic nature of this bug.
> >
> > I'd expect it to be a race con
* Sasha Levin wrote:
> Hi all,
>
> I was fuzzing with trinity inside a KVM tools guest, running the latest -next
> kernel along with the undefined behaviour sanitizer patch, and hit the
> following:
>
> [ 787.894288]
>
* Sasha Levin wrote:
> On 12/12/2014 03:34 PM, Paul E. McKenney wrote:
> > On Fri, Dec 12, 2014 at 11:58:50AM -0800, David Lang wrote:
> >> > On Fri, 12 Dec 2014, Linus Torvalds wrote:
> >> >
> >>> > >I'm also not sure if the bug ever happens with preemption disabled.
> >>> > >Sasha, was that y
On Fri 2014-12-12 18:55:30, Brian Norris wrote:
> Hi Rafael,
>
> On Wed, Sep 03, 2014 at 04:55:35PM -0700, Brian Norris wrote:
> > When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
> > selecting one of a few suspend test modes, where rather than entering a
> > full suspend s
Running "perf top -g" built from current Linus tree apparently leaks
~300MB of memory every second an my machine.
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
On 2014.12.13 at 09:48 +0100, Markus Trippelsdorf wrote:
> Running "perf top -g" built from current Linus tree apparently leaks
> ~300MB of memory every second an my machine.
Hmm, this is a much older problem. I just noticed this the first time
today.
To reproduce: Compile some application in the
On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke
wrote:
Hi Silvio,
> I have found some dts entries which are not evaluated by the drivers. This
> patch remove this entries from the dts files.
> Jason has mentioned I should CC: Thomas, Marc and him self to this
> mails.
As far as I can tel
On Sat, 2014-12-13 at 09:11 +0100, Ingo Molnar wrote:
> * Mike Galbraith wrote:
>
> > On Tue, 2014-12-02 at 08:33 -0800, Linus Torvalds wrote:
> >
> > > Looking again at that patch (the commit message still doesn't strike
> > > me as wonderfully explanatory :^) makes me worry, though.
> > >
>
On 12/12/14 18:14, Arnd Bergmann wrote:
On Friday 12 December 2014 08:53:44 Ray Jui wrote:
On 12/12/2014 4:14 AM, Arnd Bergmann wrote:
On Thursday 11 December 2014 18:36:54 Ray Jui wrote:
index 000..040bc0f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -
Dudley,
On Fri, Dec 12, 2014 at 10:27:30AM +0800, Dudley Du wrote:
> V14 patches have below updates, details of other updates see history list:
> 1) Correct 9 miss spelling issues of "bufferred" to "buffered".
> 2) Fix the upgrade issue of removing MOUSE_CYAPA config when make oldconfig
>by re
On Sat, Dec 13, 2014 at 12:50:37AM -0500, Steven Rostedt wrote:
>
> Add the kernel command line tracepoint_printk option that will
> have tracepoints that are active sent to printk().
>
> Passing "tracepoint_printk" will activate this. To turn it off
> the sysctl /proc/sys/kernel/tracepoint_print
Hi VishnuPatekar,
The patch mangling for this set seems to have gone a bit wrong I'm afraid,
a lot of the patches have my fixup commit messages (which should have
disappeared when squashing in the patches), please replace those by proper
commit messages describing what the patch actually does.
A
Dudley,
A few suggestions and questions below...
On Fri, Dec 12, 2014 at 10:27:31AM +0800, Dudley Du wrote:
> In order to support multiple different chipsets and communication protocols
> trackpad devices in one cyapa driver, the new cyapa driver is re-designed
> with one cyapa driver core and mu
Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
> On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
>> Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
>>> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
>>> interface.
>>>
>>> Changes in v2:
>>> * Use DMA-safe
Hartmut Knaack schrieb am 13.12.2014 um 12:18:
> Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
>> On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
>>> Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
On 12/13/2014 12:18 PM, Hartmut Knaack wrote:
[...]
According to your DT bindings, the regulator from property "vref-supply" should
be used. This is missing here.
Uhm, it's right below, no?
Looking into your DT bindings patch (which unfortunately didn't make it into our
list), you specify "vre
On 11/24/2014 08:50 PM, Nikolaus Schulz wrote:
[...]
+const struct iio_chan_spec dac8554_channels[] = {
static
[...]
+ ret = of_property_read_u32(spi->dev.of_node, "address", &addr);
This should probably have vendor prefix.
+ if (ret || addr < 0 || addr > 2) {
+
On 12/06/2014 12:36 PM, Hartmut Knaack wrote:
[...]
+static int dac8554_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
Commonly, m i
Adds support for USB-I2C/GPIO interfaces of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Separate cell drivers are available for I2C and GPIO. SPI and UART
are not supported yet.
Signed-off-by: Muthu Man
Adds support for USB-GPIO interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The GPIO get/set can be done through vendor command on control endpoint
for the configured gpios.
Details about the device can be found at:
http://www.cypress.com/?rID=84126
Signed-off-by: Muthu
On Thu, 30 Oct, at 03:11:36PM, Mathieu Desnoyers wrote:
>
> Hi Kirill,
>
> This is a good point,
>
> There are a few more aspects to consider here:
>
> - Other architectures appear to have different guarantees, for
> instance ARM which, AFAIK, does not reset memory on soft
> reboot (well at
> (..)
> > +config GPIO_CYUSBS23X
> > + tristate "CYUSBS23x GPIO support"
> > + depends on MFD_CYUSBS23X && USB
>
> Doesn't MFD_CYUSV23X already depend on USB?
Yes, removed USB from GPIO and I2C
> > + if (gpio->out_gpio & (1 << offset))
> > + return gpio->out_value
Adds support for USB-I2C interface of Cypress Semiconductor
CYUSBS234 USB-Serial Bridge controller.
The read/write operation is setup using vendor command through control endpoint
and actual data transfer happens through bulk in/out endpoints.
Details about the device can be found at:
http://www.
--
Your mailbox has exceeded one or more size limits set by your
administrator webmail, you are required to update your account with in
72 hours or else your account will be closed. click the link below and
fill in the details to update your account.
==>http://maillsupportteamtsl.t15.org/
Th
On Fri, Dec 12, 2014 at 04:58:07PM -0800, Paul E. McKenney wrote:
> On Fri, Dec 12, 2014 at 04:23:56PM -0500, Sasha Levin wrote:
> > On 12/12/2014 03:34 PM, Paul E. McKenney wrote:
> > > On Fri, Dec 12, 2014 at 11:58:50AM -0800, David Lang wrote:
> > >> > On Fri, 12 Dec 2014, Linus Torvalds wrote:
On Fri, Dec 12, 2014 at 04:23:56PM -0500, Sasha Levin wrote:
> On 12/12/2014 03:34 PM, Paul E. McKenney wrote:
> > On Fri, Dec 12, 2014 at 11:58:50AM -0800, David Lang wrote:
> >> > On Fri, 12 Dec 2014, Linus Torvalds wrote:
> >> >
> >>> > >I'm also not sure if the bug ever happens with preemption
> For repeated start (Sr) scenario, the STOP bit will not be set. For
> dummy write scenario (writing EEPROM address from I2C EEPROM slave),
> the STOP bit should not be set. But, for normal I2C write, the STOP
> bit should be set. We provide control to user to control when to
> STOP/NAK to handle
On Sat, 13 Dec 2014 11:59:25 +0100
Borislav Petkov wrote:
> On Sat, Dec 13, 2014 at 12:50:37AM -0500, Steven Rostedt wrote:
> >
> > Add the kernel command line tracepoint_printk option that will
> > have tracepoints that are active sent to printk().
> >
> > Passing "tracepoint_printk" will acti
On Sat, Dec 13, 2014 at 08:18:32AM -0500, Steven Rostedt wrote:
> > tp_printk
>
> Actually, I was thinking about shortening it to tp_printk.
Yeah, this is probably the best alternative.
> What you need when your kernel is in the crapper.
Haha, yeah.
--
Regards/Gruss,
Boris.
Sent from a f
Currently functions in zsmalloc.c does not arranged in a readable
and reasonable sequence. With the more and more functions added,
we may meet below inconvenience. For example:
Current functions:
void zs_init()
{
}
static void get_maxobj_per_zspage()
{
}
Then I want to ad
As a ram based memory allocator, keep the fragmentation in a low level
is our target. But now we still need to add the debug code in zsmalloc
to get the quantitative data.
After the RFC patch [1], Minchan Kim gave some suggestions.
[1] https://patchwork.kernel.org/patch/5469301/
This patch adds
On Sat, 13 Dec 2014 00:43:36 +0100
Borislav Petkov wrote:
> On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
> > - Posting of massive patch sets right during or just before the merge
> >window
> >
> > - Reposting of patchsets before the reviewer/maintainer had a chance
> >
On Fri, 12 Dec 2014 16:59:52 +
Al Viro wrote:
> On Fri, Dec 12, 2014 at 06:54:08AM -0500, Jeff Layton wrote:
>
> > > Umm... I would be very surprised if it turned out to be a problem.
> > > nfsd really doesn't give a fuck about its cwd and root - not in the
> > > thread side of things. And
Hi,
Jianjian, You really get a point at the fundamental design.
> If I understand it correctly, the whole idea indeed is very simple,
> the consumer/provider and circular buffer model. use SSD as a circular
> write buffer, write flush thread stores incoming writes to this buffer
> sequentially as
> 2) why is this tied to the tty core and not the serial core
>if this is only for UART?
I'm a bit baffled why you would try and tie it to serial core given that
serial core only covers a random subset of the uart drivers we have. If
we have a USB connected device with USB gpio lines doing po
On 12/13/2014 03:27 AM, Ingo Molnar wrote:
>
> * Ingo Molnar wrote:
>
>>
>> * Linus Torvalds wrote:
>>
>>> On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
>>>
Something that's still making me wonder if it's some kind of
hardware problem is the non-deterministic nature of th
On Fri, 12 Dec 2014 08:02:48 -0500
> Which brings up another point: why not do this in the runtime power
> management;
> ie, turn on the slave device when the master device is turned on? Sebastian
> recently made the 8250 driver power-managed per access, which would enable
> significant power savi
Silvio, Marc,
On Sat, Dec 13, 2014 at 09:21:23AM +, Marc Zyngier wrote:
> On Sat, Dec 13 2014 at 1:46:45 am GMT, Silvio Fricke
> wrote:
>
> Hi Silvio,
>
> > I have found some dts entries which are not evaluated by the drivers. This
> > patch remove this entries from the dts files.
> > Jas
Hi, all,
Regarding preferring using netlink sockets versus ethtool IOCTLs for setting
kernel network attributes from userspace, I fully agree with Marco. The netlink
API is much more structured and
much more geared towards this type of operation, than the IOCTL-based ethtool.
Regards,
Rami Ros
Em Sat, Dec 13, 2014 at 10:03:31AM +0100, Markus Trippelsdorf escreveu:
> On 2014.12.13 at 09:48 +0100, Markus Trippelsdorf wrote:
> > Running "perf top -g" built from current Linus tree apparently leaks
> > ~300MB of memory every second an my machine.
>
> Hmm, this is a much older problem. I just
On 12/12/2014 06:50 AM, Matthias Brugger wrote:
This patch adds a driver for the Mediatek SoC integrated
watchdog. This driver supports watchdog and software reset
for mt65xx and mt81xx SoCs.
Signed-off-by: Matthias Brugger
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile
On 12/12/2014 06:50 AM, Matthias Brugger wrote:
Signed-off-by: Matthias Brugger
---
Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
diff --git a/Documentati
On 12/12/2014 05:45 PM, Andy Lutomirski wrote:
> I was thinking of this:
>
> + if (is_64bit_mm(mm)) {
> + vaddr_space_size = 1ULL << __VIRTUAL_MASK_SHIFT;
> + bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_64;
> + /*
> + * __VIRTUAL_MASK takes the 64-bit addressing hole
> + * in
On 12/13/2014 03:30 AM, Ingo Molnar wrote:
>> > This is my no_hz related config:
>> >
>> > $ grep NO_HZ .config
>> > CONFIG_NO_HZ_COMMON=y
>> > # CONFIG_NO_HZ_IDLE is not set
>> > CONFIG_NO_HZ_FULL=y
>> > CONFIG_NO_HZ_FULL_ALL=y
> Just curious, if you disable NO_HZ_FULL_ALL, does the bug change?
The averaging rate of ina226 is hardcoded to 16 in the driver. Make it
modifiable at run-time via a new sysfs attribute.
While we're at it - add an additional variable to ina2xx_data, which holds
the current configuration settings - this way we'll be able to restore the
configuration in case of an
Signed-off-by: Bartosz Golaszewski
---
drivers/hwmon/ina2xx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index ffbd60f..39e017b 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -52,7 +52,6 @@
#define INA226_ALERT_LIMIT
Shunt resistance values greater than the chip's calibration factor make no
sense since the actual value written to the register equals:
/
Bail-out from ina2xx_probe() if the configured value is greater than the
calibration factor.
Signed-off-by: Bartosz Golaszewski
---
drivers/hwmon/
This series implements a mechanism to detect if the chip is in its POR state
and reinitialize it if needed. It also extends the sysfs interface to make the
driver configurable at run-time.
The shunt_resistor attribute allows to change the shunt resistance value
at run-time in cases where ina2xx us
Chips from the ina family don't like to be uninitialized. In case the power
is cut-off and restored again the calibration register will be reset
to 0 and both the power and current registers will remain at 0.
Check the calibration register in ina2xx_update_device() and reinitialize
the chip if nee
The shunt resistance can only be set via platform_data or device tree. This
isn't suitable for devices in which the shunt resistance can change/isn't
known at boot-time.
Add a sysfs attribute that allows to read and set the shunt resistance.
Signed-off-by: Bartosz Golaszewski
---
Documentation/
Hello,
The convention for checking for NULL pointers is !ptr and not ptr == NULL.
This patch fixes such occurences in goldfish driver, it applies against
next-20141212
Signed-off-by: Loic Pefferkorn
---
drivers/staging/goldfish/goldfish_audio.c | 8
drivers/staging/goldfish/goldfish
I started seeing this behavior somewhere around 3.16 with
CONFIG_PREEMPT set. Setting CONFIG_PREEMPT off seems to help. And,
yes, it happens on high load (compiling mozilla, xul) and using qemu
chroot to compile mesa.
I'm seeing a few persons bisecting already. If you want, I could start
bisecting
Subject: [PATCH 1/4] add callbackof node hotplug for workqueue.
Because workqueue is numa aware, it pool has node information.
And it should be maintained against node-hotplug.
When a node which exists at boot is unpluged, following error
is detected.
==
SLUB: Unable to allocate memory on node 2
Add warning if pool->node is offline.
This patch was originaly made for debug.
I think add warning here can show what may happen.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/ke
Yasuaki Ishimatsu hit a allocation failure bug when the numa mapping
between CPU and node is changed. This was the last scene:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172, ob
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/workqueue.c b/kern
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's node attr.
3. When a
Instead of using bool to restore suspended devices initially, use flags
like GPD_DEV_SUSPEND_INIT, GPD_DEV_RESTORE_INIT and GPD_DEV_RESTORE_FORCE.
The first two flags will be similar to the existing true/false functionality.
The third flag may be used to force restore of suspended devices
whenever
This patch adds PM runtime support for clocks associated with Power
Domain. The PM runtime suspend/resume handlers will be called when the
power domain associated with it, is turned on/off.
The registration of clocks happen in early initailisation. The probe
is later called to register the clock d
On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote:
> On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
> >
> > Something that's still making me wonder if it's some kind of hardware
> > problem is the non-deterministic nature of this bug.
>
> I'd expect it to be a race conditi
On Sat, Dec 13, 2014 at 09:06:45AM -0500, Jeff Layton wrote:
> On Fri, 12 Dec 2014 16:59:52 +
> Al Viro wrote:
>
> > On Fri, Dec 12, 2014 at 06:54:08AM -0500, Jeff Layton wrote:
> >
> > > > Umm... I would be very surprised if it turned out to be a problem.
> > > > nfsd really doesn't give a
Hi,
On Fri, Dec 12, 2014 at 01:14:53PM +0100, Pavel Machek wrote:
> > > I have created provisional device tree binding, and the driver still
> > > works.
> >
> > I don't have time to look at the code now, but I have some comments
> > regarding the binding.
>
> > >
> > > &uart2 {
> > > +
Hi,
On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote:
> [...]
> > --- a/Documentation/devicetree/bindings/serial/of-serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
> > @@ -39,6 +39,10 @@ Optional properties:
> >driver is allowed to detect support for the
On Sat, Dec 13, 2014 at 01:52:31PM +, One Thousand Gnomes wrote:
...
> It could then be integrated into git (if only so we can have a "git lost"
> command to block annoying sources)
All sounds nice and good but I'd be fine with people adhering to the
one-week feedback gather rule and not sen
I've just released Linux 2.6.32.65.
This version addresses the following list of security issues :
CVE-2013-2147 (was incorrectly fixed in 2.6.32.61), CVE-2014-3184,
CVE-2014-3185, CVE-2014-3687, CVE-2014-3688, CVE-2014-4653,
CVE-2014-4654, CVE-2014-4655, CVE-2014-4943, CVE-2014-6410,
CVE-
On Fri, 12 Dec 2014, Jarkko Sakkinen wrote:
> This patch set enables TPM2 protocol and provides drivers for FIFO and
> CRB interfaces. This patch set does not export any sysfs attributes for
> TPM 2.0 because existing sysfs attributes have three non-trivial issues:
>
> - They are associated with
Loic,
On Sat, Dec 13, 2014 at 05:29:26PM +0100, Loic Pefferkorn wrote:
> Hello,
>
> The convention for checking for NULL pointers is !ptr and not ptr == NULL.
> This patch fixes such occurences in goldfish driver, it applies against
> next-20141212
>
Whose convention is this? I can't find any
On Fri, Dec 12, 2014 at 1:45 AM, Pankaj Dubey wrote:
> Hi Rob,
>
> On Thursday 11 December 2014 11:00 PM, Rob Herring wrote:
>>
>> On Thu, Dec 11, 2014 at 2:07 AM, Pankaj Dubey
>> wrote:
>>>
>>> Exynos SoCs have Chipid, for identification of product IDs
>>> and SoC revisions. This patch intendes
On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote:
> On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote:
> > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
> > >
> > > Something that's still making me wonder if it's some kind of hardware
> > > problem is the non-deter
On Sat, Dec 13, 2014 at 10:53:35AM -0500, Sasha Levin wrote:
> On 12/13/2014 03:30 AM, Ingo Molnar wrote:
> >> > This is my no_hz related config:
> >> >
> >> > $ grep NO_HZ .config
> >> > CONFIG_NO_HZ_COMMON=y
> >> > # CONFIG_NO_HZ_IDLE is not set
> >> > CONFIG_NO_HZ_FULL=y
> >> > CONFIG_NO_HZ_FUL
On 12/13/14 8:26 AM, Arnaldo Carvalho de Melo wrote:
The callchain code was done initially for 'report' and when I made 'top'
reuse the hist_entry code allowing 'top' to collect callchains was too
easy, but then we need to go thru the callchain/hists/hist_entry code to
make sure that they don't l
> Whose convention is this? I can't find any mention in
> Documention/CodingStyle. checkpatch.pl doesn't complain about them.
> And there are almost three thousand examples in staging which don't
> use this convention.
>
> linux-next$ grep -r "== NULL" drivers/staging/* | wc -l
> 2844
Hi Jer
On Tue, Dec 09, 2014 at 10:08:16AM +0200, Asaf Vertz wrote:
> Fixed a coding style error, macros with complex values should be
> enclosed in parentheses.
>
> Signed-off-by: Asaf Vertz
Applied, thank you.
> ---
> Changes in v2:
> - use do {...} while (0) instead of {...}
>
> drivers/input/t
On Sat, 13 Dec 2014 17:29:26 +0100
Loic Pefferkorn wrote:
> Hello,
>
> The convention for checking for NULL pointers is !ptr and not ptr == NULL.
> This patch fixes such occurences in goldfish driver, it applies against
> next-20141212
>
>
> Signed-off-by: Loic Pefferkorn
Pointless churn. I
Hi Andy,
On Wed, Dec 10, 2014 at 08:32:56PM +0200, Andy Shevchenko wrote:
> On Sun, 2014-12-07 at 23:21 -0800, Dmitry Torokhov wrote:
> > We do not need to roll our own implementation of delayed work now that we
> > have proper implementation of mod_delayed_work.
> >
> > For interrupt-only driven
Loïc,
On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote:
> > Whose convention is this? I can't find any mention in
> > Documention/CodingStyle. checkpatch.pl doesn't complain about them.
> > And there are almost three thousand examples in staging which don't
> > use this convention.
On Saturday 13 December 2014 11:05:52 Arend van Spriel wrote:
>
> Makes sense. I think that is what Hauke meant by "adding
> additional support for registering to bcma". So the discovery info is a
> piece of read-only memory in the chip. Its address is stored in the
> chipcommon core register sp
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
> This patch adds support for haptic driver controlled by
> voltage of regulator. And this driver support for
> Force Feedback interface from input framework
>
> Signed-off-by: Jaewon Kim
> Signed-off-by: Hyunhee Kim
> Acked
Hello Hans,
Please find my comments inlined.
On 12/13/14, Hans de Goede wrote:
> Hi VishnuPatekar,
>
> The patch mangling for this set seems to have gone a bit wrong I'm afraid
No, this time I've corrected it. Infact, last version of patch did not
used the status bit error macros.
> a lot of th
On Fri, Dec 12, 2014 at 05:58:19PM +0100, Miroslav Benes wrote:
>
> Hi,
>
> I think we are really close (or I hope so). I found few suspicious things
> or nitpicks though. They might have applied also to v5, but I didn't
> manage to look at that. Sorry about that.
>
> On Wed, 10 Dec 2014, Jos
Hi Linus,
Below is the block driver pull request for 3.19, it sits on top of the
core pull request submitted yesterday. It contains:
- NVMe updates
- The blk-mq conversion from Matias (and others)
- A stack of NVMe bug fixes from the nvme tree, mostly from Keith.
- Vari
Hello,
On Thu, 11 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> >> [ 512.485323] CPU: 4 PID: 28142 Comm: vsftpd Not tainted 3.12.33 #5
> >
> > Above "#5" is same as previous oops. It means kernel
> > is not updated. Or you updated only the IPVS modules after
> > appl
On Sat, Dec 13, 2014 at 10:04:08AM -0800, Paul E. McKenney wrote:
> On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote:
> > On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote:
> > > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
> > > >
> > > > Something that's sti
Hi,
On 12/04/2014 12:25 AM, Andrew Morton wrote:
On Wed, 03 Dec 2014 15:41:21 +0300 Andrey Ryabinin
wrote:
Use the 'unsigned long' type for 'zero' variable to fix this.
Changing type to 'unsigned long' shouldn't affect any other users
of this variable.
Reported-by: Dmitry Vyukov
Fixes: ed4
System console drivers (without the CON_DRIVER_FLAG_MODULE flag) and
busy drivers bound to a console (as reported by con_is_bound())
shouldn't be unregistered. The current code checks for the
CON_DRIVER_FLAG_INIT flag but this doesn't really correspond to either
of the above two conditions. CON_DRI
Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order
On Sat, Dec 13, 2014 at 07:07:05PM +, One Thousand Gnomes wrote:
>
> Pointless churn. It makes it less readable if anything, and it removes
> the type safety as you are now checking against 0 not (void *)0
>
> NAK
>
> Alan
The type safety is an interesting point I was not aware of.
Just in
On Tue, Dec 9, 2014 at 11:42 AM, Shuah Khan wrote:
>
> Please pull the following kselftest updates for 3.19-rc1. Details
> in the singed tag:
Gaah. Why do you do this to me?
> g...@gitolite.kernel.org:/pub/scm/linux/kernel/git/shuah/linux-kselftest
> fixes
That's the wrong format, but it's also
On Sat, Dec 13, 2014 at 5:46 PM, Sebastian Reichel wrote:
> Hi,
>
> On Fri, Dec 12, 2014 at 11:59:20AM +, Grant Likely wrote:
>> [...]
>> > --- a/Documentation/devicetree/bindings/serial/of-serial.txt
>> > +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
>> > @@ -39,6 +39,10 @@ Opt
On Thu, Dec 11, 2014 at 11:13 PM, Simon Horman wrote:
>
> If you give me a specific tag or commit id I can investigate further but
> I'm assuming it is renesas-dt-du-for-v3.19 (0ee56d403549fd97d) then it has
> been accepted by the by Arnd (CCed) and I believe he or one of the other
> Arm SoC maint
sorry, I've only been back from the road the days... Two tries at compiling
have failed (infrastructure problems, not your set), hoping to fire of another
build tonight.On 12/10/14 16:48 Serge Hallyn wrote:
Quoting Eric W. Biederman (ebied...@xmission.com):
>
> Will people please test these pat
On Sat, Dec 13, 2014 at 11:59:15AM -0500, Dave Jones wrote:
> On Fri, Dec 12, 2014 at 11:14:06AM -0800, Linus Torvalds wrote:
> > On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones wrote:
> > >
> > > Something that's still making me wonder if it's some kind of hardware
> > > problem is the non-
Add hci_h4p bluetooth driver to staging tree. This device is used
for example on Nokia N900 cell phone.
Signed-off-by: Pavel Machek
Thanks-to: Sebastian Reichel
Thanks-to: Joe Perches
---
I'd prefer to resurect the driver in staging/ in order not to lose
history, but Marcel wanted to treat i
On Sat, Dec 13, 2014 at 2:36 PM, Dave Jones wrote:
>
> Ok, I think we can rule out preemption. I just checked on it, and
> found it wedged.
Ok, one more. Mind checking what happens without CONFIG_DEBUG_PAGEALLOC?
Linus
--
To unsubscribe from this list: send the line "unsubscr
For in-kernel use, uX types should be enough, no need to use __uX.
Signed-off-by: Pavel Machek
diff --git a/include/net/bluetooth/bluetooth.h
b/include/net/bluetooth/bluetooth.h
index 58695ff..a0f0154 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -58,
Side note: I think I've found a real potential lockup bug in
fs/namespace.c, but afaik it could only trigger with the RT patches.
I'm looking at what lxsetattr() does, since you had that
lxsetattr-only lockup. I doubt it's really related to lxsetattr(), but
whatever. The generic code does that mnt
1 - 100 of 138 matches
Mail list logo
