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
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.
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
> >
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
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
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
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
> 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
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
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:
--
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/
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:
> (..)
> > +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
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
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
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
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
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", );
This should probably have vendor prefix.
+ if (ret || addr < 0 || addr > 2) {
+
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
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
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
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
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.
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
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
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
@@
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 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
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
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
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
* 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
* 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]
>
* 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
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:
* 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
* 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)
> >
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:
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:
* Mike Galbraith umgwanakikb...@gmail.com 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 torva...@linux-foundation.org wrote:
On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones da...@redhat.com 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,
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 mi...@kernel.org wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones da...@redhat.com wrote:
Something that's still making me wonder if it's some kind of
hardware problem is the non-deterministic nature of
* Sasha Levin levinsasha...@gmail.com 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 sasha.le...@oracle.com 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
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 state,
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
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 silvio.fri...@gmail.com
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.
On Sat, 2014-12-13 at 09:11 +0100, Ingo Molnar wrote:
* Mike Galbraith umgwanakikb...@gmail.com 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,
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 replase
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_printk can
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.
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
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 buffer for SPI
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
interface.
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
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
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
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 least
(..)
+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 (1 offset);
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:
--
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/
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 disabled.
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 b...@alien8.de 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
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 fat
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
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
On Sat, 13 Dec 2014 00:43:36 +0100
Borislav Petkov b...@alien8.de 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
On Fri, 12 Dec 2014 16:59:52 +
Al Viro v...@zeniv.linux.org.uk 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
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
On 12/13/2014 03:27 AM, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
* Linus Torvalds torva...@linux-foundation.org wrote:
On Fri, Dec 12, 2014 at 10:54 AM, Dave Jones da...@redhat.com wrote:
Something that's still making me wonder if it's some kind of
hardware problem is
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 savings
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
silvio.fri...@gmail.com wrote:
Hi Silvio,
I have found some dts entries which are not evaluated by the drivers. This
patch remove this entries from the dts
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
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 noticed
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 matthias@gmail.com
---
drivers/watchdog/Kconfig | 10 ++
On 12/12/2014 06:50 AM, Matthias Brugger wrote:
Signed-off-by: Matthias Brugger matthias@gmail.com
---
Documentation/devicetree/bindings/watchdog/mtk-wdt.txt | 13 +
1 file changed, 13 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
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 to
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?
On 12/13/2014 07:08
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
Signed-off-by: Bartosz Golaszewski bgolaszew...@baylibre.com
---
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 @@
Shunt resistance values greater than the chip's calibration factor make no
sense since the actual value written to the register equals:
calibration factor / shunt
Bail-out from ina2xx_probe() if the configured value is greater than the
calibration factor.
Signed-off-by: Bartosz
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
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
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
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 l...@loicp.eu
---
drivers/staging/goldfish/goldfish_audio.c | 8
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
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 kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff
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,
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 kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff
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
101 - 200 of 276 matches
Mail list logo
