Hi Alex,
>> In case of any failure ieee802154fake_probe() just calls unregister_netdev().
>> But it does not look safe to unregister netdevice before it was registered.
>>
>> The patch implements straightforward resource deallocation in case of
>> failure in ieee802154fake_probe().
>>
>> Found
On Sat, Nov 15, 2014 at 02:36:17AM +0300, Dmitry Kalinkin wrote:
> +int vme_master_mmap(struct vme_resource *resource, struct vm_area_struct
> *vma)
> +{
> + struct vme_master_resource *image;
> + phys_addr_t phys_addr;
> + unsigned long vma_size;
> +
> + if (resource->type !=
Hi,
On Sat, Nov 15, 2014 at 02:11:59AM +0300, Alexey Khoroshilov wrote:
> In case of any failure ieee802154fake_probe() just calls unregister_netdev().
> But it does not look safe to unregister netdevice before it was registered.
>
> The patch implements straightforward resource deallocation in
The PDM output clock can use a divider of 1/2/3/4 based on the system clock
Signed-off-by: Ben Zhang
---
Documentation/devicetree/bindings/sound/rt5677.txt | 5 +
include/sound/rt5677.h | 8
sound/soc/codecs/rt5677.c | 7 +++
The rt5677 codec driver looks for ACPI device ID "RT5677CE",
which is specified in coreboot. This patch allows platform
data to be obtained via ACPI
Signed-off-by: Ben Zhang
---
sound/soc/codecs/rt5677.c | 52 +--
1 file changed, 50 insertions(+), 2
On Fri, 14 Nov 2014, Joe Perches wrote:
> On Fri, 2014-11-14 at 10:18 +0100, Julia Lawall wrote:
> > On Thu, 13 Nov 2014, Joe Perches wrote:
> []
> > > Yes, I agree with some of the things Al Viro said
> > > there, but isn't 'type t; t *p;' a subset of
> > > "expression *e"?
>
> > No. How would
On Fri, Nov 14, 2014 at 9:37 PM, Andy Yan wrote:
>
> We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly differences, such as phy pll configuration, register width(imx hdmi
> register is
> What's the benefit here? Seems very risky at very little gain.
>
> The juice ain't worth the squeeze. NAK
Hello,
It is fair to argue that these changes are too tiny to be very
meaningful for performance but the other goal of this patch was also
to make the code look cleaner and easier for me
Hello, thank you for the criticism.
> It's probably better to do this as three or four separate patches.
Really? Alright if you insist I'll do the next version as multiple
patches.
> Well yes, that's what EMFILE means but "too_many_open_files" doesn't
> make sense in this context!
Fair enough,
On Fri, Nov 14, 2014 at 9:39 PM, Andy Yan wrote:
> drm driver may probe before the i2c bus, so the driver should
> defer probing until it is available
>
> Signed-off-by: Andy Yan
>
> ---
>
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> Changes in v8: None
> Changes in v7:
On Fri, Nov 14, 2014 at 9:38 PM, Andy Yan wrote:
> CHECK: Alignment should match open parenthesis
> + if ((hdmi->vic == 10) || (hdmi->vic == 11) ||
> + (hdmi->vic == 12) || (hdmi->vic == 13) ||
>
> CHECK: braces {} should be used on all arms of this statement
> + if
From: "Steven Rostedt (Red Hat)"
Instead of checking the return value of trace_seq_printf() and friends
for overflowing of the buffer, use the trace_seq_has_overflowed() helper
function.
This cleans up the code quite a bit and also takes us a step closer to
changing the return values of
From: "Steven Rostedt (Red Hat)"
Adding a trace_seq_has_overflowed() which returns true if the trace_seq
had too much written into it allows us to simplify the code.
Instead of checking the return value of every call to trace_seq_printf()
and friends, they can all be called normally, and at the
From: "Steven Rostedt (Red Hat)"
If the trace_seq of ftrace_raw_output_prep() is full this function
returns TRACE_TYPE_PARTIAL_LINE, otherwise it returns zero.
The problem is that TRACE_TYPE_PARTIAL_LINE happens to be zero!
The thing is, the caller of ftrace_raw_output_prep() expects a
success
From: "Steven Rostedt (Red Hat)"
The branch tracer should not be checking the trace_seq_printf() return value
as that will soon be void. There's a new trace_handle_return() helper function
that will return TRACE_TYPE_PARTIAL_LINE if the trace_seq overflowed
and TRACE_TYPE_HANDLED otherwise.
From: "Steven Rostedt (Red Hat)"
Remove checking the return value of all trace_seq_puts(). It was wrong
anyway as only the last return value mattered. But as the trace_seq_puts()
is going to be a void function in the future, we should not be checking
the return value of it anyway.
Just return
From: "Steven Rostedt (Red Hat)"
The functions trace_seq_printf() and friends will soon no longer have
return values. Using trace_seq_has_overflowed() and trace_handle_return()
should be used instead.
Link: http://lkml.kernel.org/r/20141114011411.693008...@goodmis.org
Cc: Masami Hiramatsu
Cc:
From: "Steven Rostedt (Red Hat)"
The return values for trace_seq_printf() and friends are going to be
removed and they will become void functions. The mmio tracer checked
their return and even did so incorrectly.
Some of the funtions which returned the values were never checked
themselves.
From: "Steven Rostedt (Red Hat)"
The functions trace_seq_printf() and friends will not be returning values
soon and will be void functions. To know if they succeeded or not, the
functions trace_seq_has_overflowed() and trace_handle_return() should be
used instead.
Reviewed-by: Petr Mladek
Version 5!
Full diff between v4 and v5 will be replied to this email.
Here's the summary of the differences since version 4:
. Various clean ups
. Added trace_seq_used() to be used instead of s->seq.len
. Used seq_buf_used() instead of s->len
. Fixed output of ftrace_raw_output_prep() as
From: "Steven Rostedt (Red Hat)"
The functions trace_seq_printf() and friends will soon not have a return
value and will only be a void function. Use trace_seq_has_overflowed()
instead to know if the trace_seq operations succeeded or not.
Link:
From: "Steven Rostedt (Red Hat)"
Add a helper function seq_buf_used() that replaces the SEQ_BUF_USED()
private macro to let callers have a method to know how much of the
seq_buf was written to.
Link: http://lkml.kernel.org/r/20141114011412.170377...@goodmis.org
Link:
From: "Steven Rostedt (Red Hat)"
In facilitating the conversion of seq_file to use seq_buf,
have the seq_buf fields match the types used by seq_file.
Link: http://lkml.kernel.org/r/20141104160222.195301...@goodmis.org
Tested-by: Jiri Kosina
Acked-by: Jiri Kosina
Reviewed-by: Petr Mladek
From: "Steven Rostedt (Red Hat)"
Rewrite seq_buf_path() like it is done in seq_path() and allow
it to accept any escape character instead of just "\n".
Making seq_buf_path() like seq_path() will help prevent problems
when converting seq_file to use the seq_buf logic.
Link:
From: "Steven Rostedt (Red Hat)"
Create a seq_buf layer that trace_seq sits on. The seq_buf will not
be limited to page size. This will allow other usages of seq_buf
instead of a hard set PAGE_SIZE one that trace_seq has.
Link: http://lkml.kernel.org/r/20141104160221.864997...@goodmis.org
Link:
From: "Steven Rostedt (Red Hat)"
Add a helper function seq_buf_clear() that resets the len and readpos
fields of a seq_buf. Currently it is only used in the seq_buf_init()
but will be used later when updating the seq_file code.
Link: http://lkml.kernel.org/r/20141104160222.352309...@goodmis.org
On Fri, 14 Nov 2014 23:58:47 -0500
Steven Rostedt wrote:
> Version 5!
>
> Full diff between v4 and v5 will be replied to this email.
>
Here it is:
-- Steve
diff --git a/include/linux/seq_buf.h b/include/linux/seq_buf.h
index da211dfbcebe..9aafe0e24c68 100644
--- a/include/linux/seq_buf.h
From: "Steven Rostedt (Red Hat)"
In trace_seq_bitmask() it calls bitmap_scnprintf() not from the current
position of the trace_seq buffer (s->buffer + s->len), but instead from
the beginning of the buffer (s->buffer).
Luckily, the only user of this "ipi_raise tracepoint" uses it as the
first
From: "Steven Rostedt (Red Hat)"
Add two helper functions; seq_buf_get_buf() and seq_buf_commit() that
are used by seq_buf_path(). This makes the code similar to the
seq_file: seq_path() function, and will help to be able to consolidate
the functions between seq_file and trace_seq.
Link:
From: "Steven Rostedt (Red Hat)"
Currently seq_buf is full when all but one byte of the buffer is
filled. Change it so that the seq_buf is full when all of the
buffer is filled.
Some of the functions would fill the buffer completely and report
everything was fine. This was inconsistent with the
From: "Steven Rostedt (Red Hat)"
The seq_buf functions are rather useful outside of tracing. Instead
of having it be dependent on CONFIG_TRACING, move the code into lib/
and allow other users to have access to it even when tracing is not
configured.
The seq_buf utility is similar to the
From: "Steven Rostedt (Red Hat)"
When trigger_all_cpu_backtrace() is called on x86, it will trigger an
NMI on each CPU and call show_regs(). But this can lead to a hard lock
up if the NMI comes in on another printk().
In order to avoid this, when the NMI triggers, it switches the printk
routine
From: "Steven Rostedt (Red Hat)"
As the seq_buf->len will soon be +1 size when there's an overflow, we
must use trace_seq_used() or seq_buf_used() methods to get the real
length. This will prevent buffer overflow issues if just the len
of the seq_buf descriptor is used to copy memory.
Link:
From: "Steven Rostedt (Red Hat)"
Being able to divert printk to call another function besides the normal
logging is useful for such things like NMI handling. If some functions
are to be called from NMI that does printk() it is possible to lock up
the box if the nmi handler triggers when another
From: "Steven Rostedt (Red Hat)"
Add a seq_buf_can_fit() helper function that removes the possible mistakes
of comparing the seq_buf length plus added data compared to the size of
the buffer.
Signed-off-by: Steven Rostedt
---
kernel/trace/seq_buf.c | 15 ++-
1 file changed, 10
From: "Steven Rostedt (Red Hat)"
The function bstr_printf() from lib/vsprnintf.c is only available if
CONFIG_BINARY_PRINTF is defined. This is due to the only user currently
being the tracing infrastructure, which needs to select this config
when tracing is configured. Until there is another
From: "Steven Rostedt (Red Hat)"
Checking the return code of every trace_seq_printf() operation and having
to return early if it overflowed makes the code messy.
Using the new trace_seq_has_overflowed() and trace_handle_return() functions
allows us to clean up the code.
In the future,
From: "Steven Rostedt (Red Hat)"
Instead of doing individual checks all over the place that makes the code
very messy. Just check trace_seq_has_overflowed() at the end or in
strategic places.
This makes the code much cleaner and also helps with getting closer
to removing the return values of
From: "Steven Rostedt (Red Hat)"
The trace_seq_printf() and friends are used to store strings into a buffer
that can be passed around from function to function. If the trace_seq buffer
fills up, it will not print any more. The return values were somewhat
inconsistant and using
On Fri, Nov 14, 2014 at 6:46 PM, Kees Cook wrote:
> On Fri, Nov 14, 2014 at 6:29 PM, Yinghai Lu wrote:
>> should use attached one instead.
>>
>> 1. should use _brk_end instead of , as we only use partial of
>>brk.
>> 2. [_brk_end, pm_end) page range is already converted. aka
>>is not
On Fri, Nov 14, 2014 at 7:06 PM, Kees Cook wrote:
> On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
>>
>> [0.00] .text: [0x0100-0x0200d548]
>> [0.00] .rodata: [0x0220-0x02a1cfff]
>> [0.00] .data: [0x02c0-0x02e50e7f]
>> [0.00] .init:
On 14/11/13, Steve Grubb wrote:
> On Thursday, November 13, 2014 08:08:52 PM Richard Guy Briggs wrote:
> > > So what terrible things happen to userspace if
> > > AUDIT_VERSION_BACKLOG_WAIT_TIME becomes 0x03 instead of 0x02?
> >
> > But it won't. It gets the value of
> >
.562343] kernel BUG at fs/9p/vfs_addr.c:190!
[ 367.564239] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[ 367.566991] Dumping ftrace buffer:
[ 367.568481](ftrace buffer empty)
[ 367.569914] Modules linked in:
[ 367.570254] CPU: 3 PID: 8234 Comm: kworker/u52:1 Not tainted
3.18.
On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
>> When setting up permissions on kernel memory at boot, the end of the
>> PMD that was split from bss remained executable. It should be NX like
>> the rest. This performs a PMD alignment
On 11/14/2014 08:43 AM, Andrey Ryabinin wrote:
> 2014-10-20 5:40 GMT+03:00 Sasha Levin :
>> gcc5 changes the default standard to c11, which makes kernel
>> build unhappy.
>>
>> Explicitly define the kernel standard to be gnu89 which should
>> keep everything working exactly like it was before
On Fri, Nov 14, 2014 at 05:09:55AM +0400, Andrey Utkin wrote:
> There's no such thing as "list_struct".
>
> Signed-off-by: Andrey Utkin
May as well get group rates on the acks... ;-)
Acked-by: Paul E. McKenney
> ---
> drivers/gpu/drm/radeon/mkregtable.c | 24
>
On Fri, Nov 14, 2014 at 6:29 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
>> On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
>>> v2:
>>> - added call to free_init_pages(), as suggested by tglx
>
>> something is wrong:
>>
>> [7.842479] Freeing unused kernel
On Sat, Nov 15, 2014 at 01:36:41AM +0100, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Dave Jones wrote:
>
> > On Fri, Nov 14, 2014 at 11:55:30PM +0100, Thomas Gleixner wrote:
> >
> > > So this looks more like a smp function call fuckup.
> > >
> > > I assume Dave is running that
On 11/10/2014 11:03 AM, Peter Zijlstra wrote:
> On Fri, Nov 07, 2014 at 10:48:27PM -0500, Sasha Levin wrote:
>> > [ 829.539183] BUG: spinlock recursion on CPU#10, trinity-c594/11067
>> > [ 829.539203] lock: 0x880631dd6b80, .magic: dead4ead, .owner:
>> > trinity-c594/11067, .owner_cpu: 13
>
On Fri, Nov 14, 2014 at 5:29 PM, Yinghai Lu wrote:
> On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
>> v2:
>> - added call to free_init_pages(), as suggested by tglx
> something is wrong:
>
> [7.842479] Freeing unused kernel memory: 3844K (82e52000 -
> 83213000)
> [
On Fri, Nov 14, 2014 at 05:17:05PM +0100, Ard Biesheuvel wrote:
> On 14 November 2014 16:43, Herbert Xu wrote:
> > While working on the cryptd request reordering problem, I noticed
> > an anomaly where kernel threads are normally allowed to use simd
> > per may_use_simd, but as soon as you
This adds support for the N900's battery to the
Nokia N900 DTS file.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/omap3-n900.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index bc82a12..39778e5 100644
On 11/13/2014 08:31 PM, Florian Fainelli wrote:
> dma_debug_init() is called by architecture specific code at different
> levels, but typically as a fs_initcall due to the debugfs
> initialization. Some platforms may have early callers of the DMA-API,
> running prior to the fs_initcall() level,
On Fri, Nov 14, 2014 at 2:55 PM, Thomas Gleixner wrote:
>
> This stale entry is not relevant here because the thing is stuck in
> generic_exec_single().
That wasn't really my argument. The fact that "do_flush_tlb_all()" was
left over on the stack frame implies that we're not doing the
Add si4713 node to the N900 device tree file.
Signed-off-by: Sebastian Reichel
---
arch/arm/boot/dts/omap3-n900.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 9b0494a..81c99f3 100644
---
Hi,
On Fri, Nov 14, 2014 at 04:47:02PM -0600, George McCollister wrote:
> Felipe,
>
> Thank you for your reply.
no problem
> >> + vbat: fixedregulator@0 {
> >> + compatible = "regulator-fixed";
> >> + regulator-name = "vbat";
> >> +
On Fri, Nov 14, 2014 at 5:32 AM, Mel Gorman wrote:
>
> This series is very heavily based on patches from Linus and Aneesh to
> replace the existing PTE/PMD NUMA helper functions with normal change
> protections. I did alter and add parts of it but I consider them relatively
> minor contributions.
On Sat, 15 Nov 2014, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Anatol Pomozov wrote:
> > On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner wrote:
> > >> So what I suppose to do with my patch? If it does not work could
> > >> anyone provide patch that removes ARM arch dependency from
> > >>
On Fri, Nov 14, 2014 at 9:10 AM, Will Deacon wrote:
>
> Cc: Linus Torvalds
Make that an Acked-by, it still looks fine to me.
Linus
--
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
On Fri, Nov 14, 2014 at 12:45 PM, Kees Cook wrote:
> When setting up permissions on kernel memory at boot, the end of the
> PMD that was split from bss remained executable. It should be NX like
> the rest. This performs a PMD alignment instead of a PAGE alignment to
> get the correct span of
On 2014/11/15 1:35, Marc Zyngier wrote:
> On 14/11/14 15:41, Jiang Liu wrote:
>> On 2014/11/14 23:31, Marc Zyngier wrote:
>>> On 12/11/14 13:43, Thomas Gleixner wrote:
From: Jiang Liu
Signed-off-by: Jiang Liu
Cc: Bjorn Helgaas
Cc: Grant Likely
Cc: Marc Zyngier
On Fri, Nov 14, 2014 at 4:52 PM, Luck, Tony wrote:
>> causes Tony's MCE stress test to fail, presumably when some CPU either
>> becomes permanently non-interruptable or otherwise wanders off into
>> the weeds.
>
> It might be that recent "improvements" I made to my test harness have
> messed
On Fri, Nov 14, 2014 at 1:10 PM, Luis R. Rodriguez
wrote:
> On Fri, Nov 14, 2014 at 12:54 PM, Johannes Berg
> wrote:
>> On Fri, 2014-11-14 at 12:52 -0800, Luis R. Rodriguez wrote:
>>> On Fri, Nov 14, 2014 at 12:50 PM, Johannes Berg
>>> wrote:
>>> > On Tue, 2014-11-11 at 00:14 -0800, Luis R.
On Saturday, November 15, 2014 02:30:51 AM Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> After multiple GPEs have been disabled at the low level in one go,
> like when acpi_disable_all_gpes() is called, we should always drain
> all of the outstanding events from them, or the ACPICA's
From: Rafael J. Wysocki
After multiple GPEs have been disabled at the low level in one go,
like when acpi_disable_all_gpes() is called, we should always drain
all of the outstanding events from them, or the ACPICA's GPE handling
code may re-enable one of them as a result of a race condition.
On Fri, 14 Nov 2014, Anatol Pomozov wrote:
> On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner wrote:
> >> So what I suppose to do with my patch? If it does not work could
> >> anyone provide patch that removes ARM arch dependency from
> >> tegra20_timer.c?
> >
> > Huch? You want other people to
On 11/14/2014 03:03 PM, Anatol Pomozov wrote:
Hi
On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote:
On Mon, 10 Nov 2014, Anatol Pomozov wrote:
On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding
wrote:
On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote:
ARM timekeeping
On Wed, Nov 12, 2014 at 09:27:50AM -0800, Christoph Hellwig wrote:
> > +static int stex_reboot_callback(struct notifier_block *self,
> > + unsigned long val,
> > + void *data)
> > +{
> > + if
Hi Linus,
The following changes since commit 7881c64716f3a7d60b325ed0ad4d15f49b474a43:
power: ab8500_fg: Fix build warning (2014-10-05 02:10:20 +0200)
are available in the git repository at:
git://git.infradead.org/battery-2.6.git tags/for-v3.18-rc
for you to fetch changes up to
> causes Tony's MCE stress test to fail, presumably when some CPU either
> becomes permanently non-interruptable or otherwise wanders off into
> the weeds.
It might be that recent "improvements" I made to my test harness have
messed things up. I trimmed one delay (between injection and
Hi
On Fri, Nov 14, 2014 at 4:18 PM, Thomas Gleixner wrote:
> On Fri, 14 Nov 2014, Anatol Pomozov wrote:
>> On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote:
>> > On Mon, 10 Nov 2014, Anatol Pomozov wrote:
>> >> On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding
>> >> wrote:
>> >> > On Fri,
On Friday, November 14, 2014 11:53:07 PM James Hogan wrote:
> On Fri, Nov 14, 2014 at 01:32:56PM -0800, Dmitry Torokhov wrote:
> > irq_of_parse_and_map() returns 0 on error, so testing for negative
> > result never works.
> >
> > Signed-off-by: Dmitry Torokhov
>
> Good catch, thanks!
>
>
On Thu, Nov 13, 2014 at 07:59:27PM -0800, Yinghai Lu wrote:
> Aaron reported 32bit/PAE mode, has problem with 64bit resource.
>
> [6.610012] pci :03:00.0: reg 0x10: [mem 0x383fffc0-0x383fffdf
> 64bit pref]
> [6.622195] pci :03:00.0: reg 0x20: [mem
On Fri, 14 Nov 2014, Dave Jones wrote:
> On Fri, Nov 14, 2014 at 11:55:30PM +0100, Thomas Gleixner wrote:
>
> > So this looks more like a smp function call fuckup.
> >
> > I assume Dave is running that stuff on KVM. So it might be worth while
> > to look at the IPI magic there.
>
> no,
In certain suspend modes on certain boards the 8250 UART may lose
state when the device goes to suspend. If we're using
no_console_suspend this can cause lots of problems during resume.
Let's cache the basic UART config registers at suspend time and if we
notice that the UART loses state (by
Hi Fabian,
> use memdup_user for rd_data import.
>
> Signed-off-by: Fabian Frederick
> ---
> net/bluetooth/hidp/core.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the
On Thu, Nov 13, 2014 at 07:59:10PM -0800, Yinghai Lu wrote:
> Aaron reported 32bit/PAE mode, has problem with 64bit resource.
>
> [6.610012] pci :03:00.0: reg 0x10: [mem 0x383fffc0-0x383fffdf
> 64bit pref]
> [6.622195] pci :03:00.0: reg 0x20: [mem
On Fri, 14 Nov 2014, Anatol Pomozov wrote:
> On Thu, Nov 13, 2014 at 2:46 PM, Thomas Gleixner wrote:
> > On Mon, 10 Nov 2014, Anatol Pomozov wrote:
> >> On Mon, Nov 10, 2014 at 1:53 AM, Thierry Reding
> >> wrote:
> >> > On Fri, Nov 07, 2014 at 11:34:15AM -0800, Anatol Pomozov wrote:
> >> >> ARM
This will be used in a later patch for clock phase tuning.
Suggested-by: Heiko Stuebner
Signed-off-by: Alexandru M Stan
---
Changes in v2: None
include/dt-bindings/clock/rk3288-cru.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/dt-bindings/clock/rk3288-cru.h
The drive and sample phases are generated by dividing an upstream parent clock
by 2, this allows us to adjust the phase by 90 deg.
There's also an option to have up to 255 delay elements (40-80 picoseconds
long).
This driver uses those elements (under the assumption that they're 60ps long) to
For now all I have is the getter and setter for the phase, nothing that uses it
(that is ready). You can test the getter like this:
localhost ~ # cat /sys/kernel/debug/clk/clk_summary|grep sample -C 1
sclk_sdio1002400 0 0
On Fri, Nov 14, 2014 at 01:32:56PM -0800, Dmitry Torokhov wrote:
> irq_of_parse_and_map() returns 0 on error, so testing for negative
> result never works.
>
> Signed-off-by: Dmitry Torokhov
Good catch, thanks!
Acked-by: James Hogan
A quick coccinelle script shows up numerous other cases of
Hi,
Am Freitag, 14. November 2014, 14:52:54 schrieb Alexandru M Stan:
> The drive and sample phases are generated by dividing an upstream parent
> clock by 2, this allows us to adjust the phase by 90 deg.
>
> There's also an option to have up to 255 delay elements (40-80 picoseconds
> long).
From: Martyn Welch
The tsi148 driver is registering the slave images as supporting the "USER"
access modes and CR/CSR access mode rather than the master images as it
should.
Remove the incorrect case entries for these modes from the
tsi148_slave_set() function, stop registering slave_images as
Dear all,
mmap() on VME bridge devices is a feature present in many existing Linux and
UNIX drivers. The proposed solution follows the approach so that mmap()
offsets are coherent with read() and write() offsets, which seems to be the
only manner compatible with the current vme_user API. It
We also make sure that user won't be able to reconfigure the window while it is
mmap'ed.
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
drivers/staging/vme/devices/vme_user.c | 85 ++
drivers/vme/vme.c | 26 +++
This implements more granular locking in vme_user_ioctl() by using separate
locks for each devfs device.
This also provides a synchronization between vme_user_read(), vme_user_write()
and vme_user_ioctl().
Signed-off-by: Dmitry Kalinkin
Cc: Igor Alekseev
---
On Wednesday, November 12, 2014 04:03:50 PM Daniel Lezcano wrote:
> The only place where the time is invalid is when the ACPI_CSTATE_FFH entry
> method is not set. Otherwise for all the drivers, the time can be correctly
> measured.
>
> Instead of duplicating the CPUIDLE_FLAG_TIME_VALID flag in
On Monday, November 10, 2014 02:14:50 PM Vince Hsu wrote:
> When the user space tries to set scaling_(max|min)_freq through
> sysfs, the cpufreq_set_policy() asks other driver's opinions
> for the max/min frequencies. Some device drivers, like Tegra
> CPU EDP which is not upstreamed yet though,
A release candidate Git v2.2.0-rc2 is now available for testing
at the usual places. We expect that the final will happen late
next week, and it will be different from this tarball only with
small documentation update changes.
The tarballs are found at:
On Thursday, November 06, 2014 03:50:59 PM Grygorii Strashko wrote:
> Hi Santosh, Kevin,
>
> I've separated these patches in standalone series as requested by
> Santosh (https://lkml.org/lkml/2014/10/24/591). Also, I've kept
> versioning of patches from original series and therefor this
> is v4
On Thursday, November 06, 2014 09:40:45 AM dirk.brande...@gmail.com wrote:
> From: Dirk Brandewie
>
> This patch set adds support for HWP. When HWP is enabled the CPU will
> do P state autonomously and intel_pstate simply provides an interface
> to forward user preferences to the CPU while
On Fri, Nov 14, 2014 at 11:55:30PM +0100, Thomas Gleixner wrote:
> So this looks more like a smp function call fuckup.
>
> I assume Dave is running that stuff on KVM. So it might be worth while
> to look at the IPI magic there.
no, bare metal.
Dave
--
To unsubscribe from this list:
On Friday, November 07, 2014 09:29:24 AM Jacob Pan wrote:
> Running Average Power Limit (RAPL) is supported in Atom processors
> with a slightly different implementation. This patchset abstracts the
> differences and add support for newer ATOM CPUs.
>
> Intel Software Developers Manual has also
On Thursday, November 13, 2014 03:10:07 PM Pavel Machek wrote:
> On Mon 2014-11-10 19:39:19, Geert Uytterhoeven wrote:
> > PM domains are powered on/off from various places. Some callers do
> > latency measurements, others don't. Consolidate using two helper
> > functions, which always measure the
On Thursday, November 13, 2014 04:26:51 PM Pavel Machek wrote:
> On Thu 2014-11-13 16:12:25, Geert Uytterhoeven wrote:
> > Hi Pavel,
> >
> > On Thu, Nov 13, 2014 at 3:09 PM, Pavel Machek wrote:
> > > Acked-by: Pavel Machek
> >
> > You've got a new email address? ;-)
>
> Yes, I decided to
From: Rasmus Villemoes
Consecutive seq_puts calls with literal strings can be merged to a
single call. This reduces the size of the generated code, and can also
lead to slight .rodata reduction (because of fewer nul and padding
bytes). It should also shave a off a few clock cycles.
Link:
From: Rasmus Villemoes
Using seq_printf to print a simple string or a single character is a
lot more expensive than it needs to be, since seq_puts and seq_putc
exist.
These patches do
seq_printf(m, s) -> seq_puts(m, s)
seq_printf(m, "%s", s) -> seq_puts(m, s)
seq_printf(m, "%c", c) ->
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next
Head SHA1: 4526d0676a150dce7a93ad93e03bef7f77e7c906
Byungchul Park (1):
function_graph: Fix micro seconds notations
Daniel Bristot de Oliveira (1):
ftrace-graph: show latency-format on
From: "Steven Rostedt (Red Hat)"
With the new logic, if only a single user of ftrace function hooks is
used, it will get its own trampoline assigned to it.
The problem is that the control_ops is an indirect ops that perf ops
uses. What that means is that when perf registers its ops with
1 - 100 of 1460 matches
Mail list logo