On Sun, 2013-09-22 at 15:22 -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 2:56 PM, Benjamin Herrenschmidt
> wrote:
> > On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
> >>
> >> We use a segment offset. Something like:
> >>
> >> inc %gs:var;
> >>
> >
> > And gcc makes no stupid
Hi Linus,
some small fixes for msm and exynos,
a regression revert affecting nouveau users with old userspace,
intel pageflip deadlock and gpu hang fixes, hsw modesetting hangs,
Dave.
The following changes since commit 928c2f0c006bf7f381f58af2b2786d2a858ae311:
drm/fb-helper: don't sleep for
On 22.09.2013 22:03, Daniel Vetter wrote:
Hm, that sounds a bit more like the ddx is having fun with rendering.
Have you tried switching the backed from to either SNA or UXA? Also
adding relevant mailing lists ...
No, whether I use uxa or sna makes no difference, same problem. I don't
think
On Sun, Sep 22, 2013 at 2:56 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
>>
>> We use a segment offset. Something like:
>>
>> inc %gs:var;
>>
>
> And gcc makes no stupid assumptions that this gs doesn't change ? That's
> the main problem we have
Hi Peter,
2013-09-22 Peter Senna Tschudin :
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @@
>
On Sun, 22 September 2013 17:27:52 -0400, Theodore Ts'o wrote:
>
> The structure of the mixing functions in /dev/random has been well
> studied, and validatetd in a number of different academic papers. So
> I prefer to stick with the basic architecture, even as it is scaled
> down for speed
On Sun, Sep 22, 2013 at 2:55 PM, Jens Axboe wrote:
>
> Mike Christie (1):
> If the queue is dying then we only call the rq->end_io callout.
> This leaves bios setup on the request, because the caller assumes when
> the blk_execute_rq_nowait/blk_execute_rq call has completed that
On Sun, 2013-09-22 at 10:47 -0700, H. Peter Anvin wrote:
> On 09/22/2013 09:24 AM, Peter Zijlstra wrote:
> >
> > As to the problem of GCC moving r13 about, some archs have some
> > exceptions in the register allocator and leave some registers alone.
> > IIRC MIPS has this and uses one of those
On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
> On Sun, Sep 22, 2013 at 02:41:01PM +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2013-09-22 at 14:39 +1000, Benjamin Herrenschmidt wrote:
> > > How do you do your per-cpu on x86 ?
>
> We use a segment offset. Something like:
>
>
Hi Linus,
After merge window, no new stuff this time only a collection of neatly
confined and simple fixes. Please pull!
git://git.kernel.dk/linux-block.git for-3.12/core
for you to fetch changes up to f3cff25f05f2ac29b2ee355e611b0657482f6f1d:
cfq: explicitly use 64bit divide operation
Ping?
On Mon, Sep 02, 2013 at 03:50:57PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
> > From: Russell King
> >
> > This patch adds tda998x specific parameters to allow it to be configured
> > for different boards using it.
On Sun, 22 Sep 2013, Geert Uytterhoeven wrote:
> > Thanks, but the changes required are actually much more than that -- the
> > driver has never been converted to the modern TURBOchannel API. I have
> > now dug out an old patch I was working on back in 2006 to convert this
> > driver as well as
Hello,
On Sun, Sep 22, 2013 at 10:24:36PM +0400, Sergei Shtylyov wrote:
>Not sure why you asked -- I'm not using this driver, neither I'm
Well, you have better grip of what's going on in the embedded world
than me. I'm mostly curious whether adding dependency on PHY is okay.
Thanks.
--
On Sun, Sep 22, 2013 at 10:03:21PM +0200, Daniel Vetter wrote:
> Hm, that sounds a bit more like the ddx is having fun with rendering.
> Have you tried switching the backed from to either SNA or UXA? Also
> adding relevant mailing lists ...
If it was just the ddx, you would observe the same
On Sat, 21 September 2013 17:41:18 -0400, Theodore Ts'o wrote:
>
> BTW, just to give another example of the difference between the mixing
> funtions, try compiling the following with and without ORIG_MIX defined...
Garbage in, garbage out again. If there is absolutely no randomness
in the input
On Thu 19-09-13 14:26:27, Andrew Morton wrote:
> On Thu, 5 Sep 2013 17:46:12 +0200 Jan Kara wrote:
> > On Fri 23-08-13 12:58:22, Andrew Morton wrote:
> > > On Fri, 23 Aug 2013 21:48:36 +0200 (CEST) Jiri Kosina
> > > wrote:
> > >
> > > > > > We have customers (quite a few of them actually)
Hello,
On Sun, Sep 22, 2013 at 10:22:31PM +0400, Sergei Shtylyov wrote:
> >@@ -37,6 +37,7 @@
> >
> > #include
> > #include
> >+#include
>
> struct phy;
>
> should suffice.
Unless it's actually likely to cause inclusion loop, I think it's
better to include the header than adding explicit
On Wed 18-09-13 16:56:08, Michal Suchanek wrote:
> On 17 September 2013 23:13, Jan Kara wrote:
> > Hello,
> >
> > On Tue 17-09-13 15:31:31, Michal Suchanek wrote:
> >> On 5 September 2013 12:12, Michal Suchanek wrote:
> >> > On 26 August 2013 15:51, Michal Suchanek wrote:
> >> >> On 12 March
On Thu 19-09-13 10:40:30, Mel Gorman wrote:
> On Thu, Sep 19, 2013 at 10:32:50AM +0100, Mel Gorman wrote:
> > Commit ffecfd1a (block: optionally snapshot page contents to provide
> > stable pages during write) uses bounce buffers for stable page writes in
> > jbd and ext3. Simplistically,
On Thu, Sep 12, 2013 at 11:01:29PM +0200, Ondrej Zary wrote:
> The test for 2nd I/O port validity is broken (reversed):
> On devices with no control port, the driver attempts to use invalid port 0,
> resulting in logs full of bad_io_access errors.
> On devices with control port, the driver does
On Sun, Sep 22, 2013 at 02:21:48PM -0700, H. Peter Anvin wrote:
> Is this really an improvement on a system with plenty of entropy? Would it
> not make more sense to modulate this bad on entropy production rates?
>
> Also, the urandom pool is only reseeded once per read, no matter how large...
On 09/15/2013 11:08:35 PM, Rusty Russell wrote:
Predates git, does anyone remember the rationale?
Depends which git: http://landley.net/kdocs/fullhist/ :)
Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Hi Varad,
On Sun, Sep 22, 2013 at 6:10 PM, Varad Gautam wrote:
>> What I'm doing wrong? I want it to use my .config, I don't want to
>> answer all the thousands questions it prompts me (I don't know all the
>> options to know what should go and what should not, hence I want it to
>> use my
On Sat, 21 September 2013 17:25:10 -0400, Theodore Ts'o wrote:
> On Mon, Sep 16, 2013 at 11:40:27AM -0400, Jörn Engel wrote:
> >
> > Here is a patch to make add_interrupt_randomness() significantly
> > cheaper without significantly impacting the quality. The second part
> > is my personal
On Sun, Sep 22, 2013 at 11:01:42PM +0200, Jörg-Volker Peetz wrote:
> just out of interest I would like to ask why this mixing function has to be
> that
> complicated. For example, even if the input is always 0 and the pool is seeded
> with pool[0] = 1 (as in your test program) this algorithm
Is this really an improvement on a system with plenty of entropy? Would it not
make more sense to modulate this bad on entropy production rates?
Also, the urandom pool is only reseeded once per read, no matter how large...
Theodore Ts'o wrote:
>In order to avoid draining the input pool of its
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> The of_irq_to_resource() helper that is used to implement of_irq_count()
> tries to resolve interrupts and in fact creates a mapping for resolved
> interrupts. That's pretty heavy lifting for something that claims to
> just return the
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Replace some instances of of_irq_map_one()/irq_create_of_mapping() and
> of_irq_to_resource() by the simpler equivalent irq_of_parse_and_map().
>
> Signed-off-by: Thierry Reding
Acked-by: Rob Herring
> ---
> arch/arm/mach-u300/timer.c
> What I'm doing wrong? I want it to use my .config, I don't want to
> answer all the thousands questions it prompts me (I don't know all the
> options to know what should go and what should not, hence I want it to
> use my current configuration).
Hi! If you want to use the existing .config file,
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Instead of returning 0 for all errors, allow the precise error code to
> be propagated. This will be used in subsequent patches to allow further
> propagation of error codes.
>
> The interrupt number corresponding to the new mapping is
On Wed, Sep 18, 2013 at 8:24 AM, Thierry Reding
wrote:
> Now that all helpers return precise error codes, this function can
> propagate these errors to the caller properly.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - return 0 on success or a negative error code on failure
> -
Hi Theodore,
Theodore Ts'o wrote, on 09/22/2013 05:05:
> The following fast_mix function, with the loop unrolling, is about 70%
> slower than your proposed version, but it's still four times faster
> than the original byte-based fast_mix function. This is what I'm
> considering using as a
Hi Alan,
thanks for your review and your constructive comments!
Alan Stern schrieb:
>On Sun, 22 Sep 2013, Kurt Garloff wrote:
>
>> Hi,
>>
>> USB devio rejects control messages when the index does not have the
>> direction bit set correctly.
>
>I wouldn't describe it that way. It would be
Hi Linus,
Please pull my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
These are mostly bug fixes and a two small performance fixes. The most
important of the bunch are Josef's fix for a snapshotting regression and
Mark's update to fix compile
In order to avoid draining the input pool of its entropy at too high
of a rate, enforce a minimum time interval between reseedings of the
urandom pool. This is set to 60 seconds by default.
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 25 +
1 file changed,
By mixing the entropy in chunks of 32-bit words instead of byte by
byte, we can speed up the fast_mix function significantly. Since it
is called on every single interrupt, on systems with a very heavy
interrupt load, this can make a noticeable different.
Signed-off-by: "Theodore Ts'o"
Recent events have inspired me to take a closer look at the /dev/random
driver and make a number of changes to improve it. The changes reflect
relatively minor changes across the entire /dev/random architecture,
including:
* how we collect entropy on non-x86 architectures
* optimizing the CPU
No point taking the spinlock twice for each call to mix_pool_bytes();
better to take it once for each pool where we add entropy.
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c
From: "H. Peter Anvin"
Allow fractional bits of entropy to be tracked by scaling the entropy
counter (fixed point). This will be used in a subsequent patch that
accounts for entropy lost due to overwrites.
Signed-off-by: H. Peter Anvin
Cc:
Signed-off-by: Theodore Ts'o
---
From: "H. Peter Anvin"
Use a macro to statically compute poolbitshift (will be used in a
subsequent patch), poolbytes, and poolbits. On virtually all
architectures the cost of a memory load with an offset is the same as
the one of a memory load.
It is still possible for this to generate worse
Jason Baron wrote:
> epoll: reduce usage of global 'epmutex' lock
>
> Epoll file descriptors that are 1 link from a wakeup source and
> are not nested within other epoll descriptors, or pointing to
> other epoll descriptors, don't need to check for loop creation or
> the
From: "H. Peter Anvin"
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless the pool is
fully empty, we are currently *guaranteed* to overestimate the amount
Fix a problem where get_random_bytes_arch() was calling the tracepoint
get_random_bytes(). So add a new tracepoint for
get_random_bytes_arch(), and make get_random_bytes() and
get_random_bytes_arch() call their correct tracepoint.
Also, add a new tracepoint for add_device_randomness()
Previously if CPU chip had a built-in random number generator (i.e.,
RDRAND on newer x86 chips), we mixed it in at the very end of
extract_buf() using an XOR operation.
We now mix it in right after the calculate a hash across the entire
pool. This has the advantage that any contribution of
Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
Videau in their paper, "The Linux Pseudorandom Number Generator
Revisited" (see: http://eprint.iacr.org/2012/251.pdf).
They suggested a slight change to improve our mixing functions
slightly. I also adjusted the comments to
Allow architectures which have a disabled get_cycles() function to
provide a random_get_entropy() function which provides a fine-grained,
rapidly changing counter that can be used by the /dev/random driver.
For example, an architecture might have a rapidly changing register
used to control random
The some platforms (e.g., ARM) initializes their clocks as
late_initcalls for some unknown reason. So make sure
random_int_secret_init() is run all of the late_initcalls are run.
Cc: sta...@vger.kernel.org
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 3 +--
Use smaller types to slightly shrink the size of the entropy store
structure.
Signed-off-by: "Theodore Ts'o"
---
drivers/char/random.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 6d5e8e6..292e717 100644
Am 22.09.2013 22:30, schrieb Markus Elfring:
>> You can do all parsing in user space too.
>
> Is it questionable when a custom prefix of a boot command-line parameter can
> not
> be mapped to a kernel module?
No.
In the systemd case we have to ensure that we never ever merge a module named
> You can do all parsing in user space too.
Is it questionable when a custom prefix of a boot command-line parameter can not
be mapped to a kernel module?
> But I'm sure it will not get merged.
Thanks for your feedback.
> All you need is a dummy module with a few module_param()s.
My ideas
On Sun, Sep 22, 2013 at 9:56 PM, Sergei Shtylyov
wrote:
> Hello.
>
> On 09/22/2013 11:50 PM, Peter Senna Tschudin wrote:
>
>You have a typo in the subject -- "brake" is a device to stop a vehicle.
> :-)
Thanks, there was other similar typo after ---
>
>
>> This patch removes the variable
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
Tested by compilation only.
CC: Joe Perches
Signed-off-by: Peter Senna Tschudin
---
Changes from V2:
- Fix typo in the subject
- Fix indentation
Changes from V1:
- Fix the indetation
-
On Sun, Sep 22, 2013 at 10:09 PM, Maciej W. Rozycki
wrote:
> Thanks, but the changes required are actually much more than that -- the
> driver has never been converted to the modern TURBOchannel API. I have
> now dug out an old patch I was working on back in 2006 to convert this
> driver as
On 09/21, Peter Hurley wrote:
>
> On 09/21/2013 02:34 PM, Oleg Nesterov wrote:
>>
>> do_each_pid_task(tty->session, PIDTYPE_SID, p) {
>> spin_lock_irq(>sighand->siglock);
>> if (p->signal->tty == tty) {
>>
On Fri, 20 Sep 2013, Joe Perches wrote:
> I do wonder how many of these still exist though.
>
> I haven't had one of those on a desk since the early
> '90's (a VAXstation w/VMS and a DECstation w/Ultrix)
DECstations seem virtually indestructible, so it's mostly the matter of
how long people
Hm, that sounds a bit more like the ddx is having fun with rendering.
Have you tried switching the backed from to either SNA or UXA? Also
adding relevant mailing lists ...
-Daniel
On Sun, Sep 22, 2013 at 7:06 PM, Thomas Richter wrote:
> Hi folks, hi Daniel,
>
> there is still an issue with
Markus,
Am 22.09.2013 21:51, schrieb Markus Elfring:
>> Why can't you use /proc/cmdline?
>
> Thanks for your suggestion.
>
>
>> (see parse_proc_cmdline())
>
> How do you think about reasons like the following?
>
> 1. I would prefer to avoid the repeated parsing of boot command-line
>
--
Webmaster Security Alert,
Your mailbox has exceeded the use of quotas, which is set
by your manager, you will not be able to creat a new e-mail
send or receive again until you validate your mailbox.
To re-validate your mailbox, by clicking this link
Hello.
On 09/22/2013 11:50 PM, Peter Senna Tschudin wrote:
You have a typo in the subject -- "brake" is a device to stop a vehicle. :-)
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
Tested by compilation only.
CC: Joe Perches
Providing a module version doesn't add any value, so drop it.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index 9b23722..db47333 100644
--- a/drivers/misc/ti_dac7512.c
+++
This way, the module can be autoloaded by the SPI core.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index 46dfbf3..6393a68 100644
--- a/drivers/misc/ti_dac7512.c
+++
Only matching is done via DT, no other details can be passed.
Signed-off-by: Daniel Mack
---
.../devicetree/bindings/misc/ti,dac7512.txt | 20
drivers/misc/ti_dac7512.c| 10 ++
2 files changed, 30 insertions(+)
create mode
Here are some trivial things for the ti_dac7512 driver.
Mark, can you take them through your spi tree?
Thanks,
Daniel
Daniel Mack (4):
drivers: misc: ti_dac7512: drop module version
drivers: misc: ti_dac7512: drop DAC7512_DRV_NAME
drivers: misc: ti_dac7512: provide a SPI ID table
> Why can't you use /proc/cmdline?
Thanks for your suggestion.
> (see parse_proc_cmdline())
How do you think about reasons like the following?
1. I would prefer to avoid the repeated parsing of boot command-line parameters
because the reuse of the kernel infrastructure should be better here.
The driver's name can be provided directly, so drop the #define.
Signed-off-by: Daniel Mack
---
drivers/misc/ti_dac7512.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
index db47333..46dfbf3 100644
---
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
Tested by compilation only.
CC: Joe Perches
Signed-off-by: Peter Senna Tschudin
---
Changes from V1:
- Fix the indetation
- Remove remaining } from removed else
Please ignore the patch:
This adds a driver for the STw481x PMICs found in the Nomadik
family of platforms. This one uses pure device tree probing.
Print some of the OTP registers on boot and register a regulator
MFD child.
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Instead of using "dummy" as the unused
On Sunday 22 September 2013 18:49:42 Tejun Heo wrote:
> Hello, Ondrej.
>
> On Fri, Sep 13, 2013 at 11:44:27PM +0200, Ondrej Zary wrote:
> > This is caused by skipping ata_sff_softreset() when ap->ioaddr.ctl_addr
> > is unset so ata_devchk() is never called. This patch seems to fix the
> >
Thanks, applied with a minor bug fix...
- Ted
commit 8484764f97a840df851f4586079f28715f13318e
Author: Dave Jones
Date: Sun Sep 22 15:31:00 2013 -0400
ext4: fix memory leak in xattr
If we take the 2nd retry path in
This patch removes the variable continual, and change the while loop
to break when efuse_data == 0xFF.
CC: Joe Perches
Signed-off-by: Peter Senna Tschudin
---
Please ignore the patch:
[PATCH 12/19] wireless: Change variable type to bool
And apply this one instead.
The variable continual was
Hi Peter,
> Convert 0 to false and 1 to true when assigning values to bool
> variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
>
> The simplified semantic patch that find this problem is as
> follows (http://coccinelle.lip6.fr/):
>
> @@
> bool b;
> @@
> (
> -b = 0
> +b =
This is also the preferred way to do it for XFS. Maybe word it in a way
that we can easily add subsystems.
To me it generally seems to be the best way to do it - having random Ccs
and lots of stable trees doesn't seem like a very good way of handling
it.
--
To unsubscribe from this list: send
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
On 09/20/2013 02:19 PM, Roger Quadros wrote:
From: Balaji T K
Add support for sata controller.
[Roger Q] Clean up.
CC: Benoit Cousson
Signed-off-by: Balaji T K
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/dra7.dtsi | 49
+++
1
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Hello.
On 09/22/2013 08:58 PM, Tejun Heo wrote:
From: Balaji T K
Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.
[Roger Q] Cleaned up.
CC: Tejun Heo
Signed-off-by: Balaji
On Sun, Sep 22, 2013 at 7:05 PM, Markus Elfring wrote:
> Hello,
>
> I became interested in an use case where I want to pass customised data from
> the
> boot command-line to other user processes. I have read the available
> documentation in the way that kernel modules provide such a means to get
Hello.
On 09/19/2013 05:05 PM, Roger Quadros wrote:
From: Balaji T K
Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.
[Roger Q] Cleaned up.
CC: Tejun Heo
Signed-off-by:
On 09/22/13 09:20, Zubair Lutfullah wrote:
> Driver is functional without this error case. Cleaned up.
>
> Signed-off-by: Zubair Lutfullah
Applied and pull request just sent to Greg.
> ---
> drivers/iio/adc/ti_am335x_adc.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git
On 09/22/13 09:20, Zubair Lutfullah wrote:
> Trigger related headers and variables are not needed
> as driver is now based on INDIO_BUFFER_HARDWARE mode
>
> Signed-off-by: Zubair Lutfullah
Applied
> ---
> drivers/iio/adc/ti_am335x_adc.c |4
> 1 file changed, 4 deletions(-)
>
> diff
The FAULT_FLAG_WRITE flag has been set based on uninitialized variable
Signed-off-by: Felipe Pena
---
arch/parisc/mm/fault.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/parisc/mm/fault.c b/arch/parisc/mm/fault.c
index d10d27a..6b38026 100644
---
Hi all! How about fix this problem ?
I have ThinkPad X230 and have micmute button, which works correctly and
LED on this button, which doesn't work.
I looked older threads[0] about this, but nothing changed since 2011..
[0]http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/1962
--
Hi,
El Sat, Sep 21, 2013 at 01:25:42PM +0100 Jonathan Cameron ha dit:
> On 09/16/13 22:17, Matthias Kaehlcke wrote:
> > The calculation of the old conversion timeout value was based on the number
> > of
> > steps used by this driver. This doesn't take into account that other steps
> > can be
On 09/22/2013 09:24 AM, Peter Zijlstra wrote:
>
> As to the problem of GCC moving r13 about, some archs have some
> exceptions in the register allocator and leave some registers alone.
> IIRC MIPS has this and uses one of those (istr there's 2) for the
> per cpu base address.
>
You can force
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare
Hi folks, hi Daniel,
there is still an issue with flicker on panning with the 835GM chipset.
As already explained, the flicker only appears if the panning position
satisfies certain alignment constraints, in specific. As long as the
plane pointer is aligned to 64 byte boundaries, everything
101 - 200 of 598 matches
Mail list logo