Quoting Tomeu Vizoso (2014-09-03 08:31:57)
In preparation to change the public API to return a per-user clk structure,
remove any usage of this public API from the clock implementations.
The reason for having this in a separate commit from the one that introduces
the implementation of the
On Thu, Aug 28, 2014 at 08:32:58PM +0530, Sudip Mukherjee wrote:
as pr_* macros are more preffered over printk, so printk replaced with
corresponding pr_* macros
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
The replacement was done by a bash script to avoid copy paste error.
This patch adds the Intersil ISL1208 and ISL12022 I2C RTCs to the
trivial-devices list. For ISL1208 a deprecated intersil,isl1208
entry is added since that is used in ppa8548.dts.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Changes since v1:
- Added deprecated entries that are still
Currently there is a wild mixture of isl, isil, and intersil compatibles
in the kernel. At this point, changing the vendor symbol to the most often
used variant, which is equal to the NASDAQ symbol, isil, should not hurt.
Patch db04d6284e2a (drivers/rtc/rtc-isl12022.c: device tree support)
added
Hi,
currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. I figure at this point it is still
possible to change this to use isil everywhere without too
much pain, but it might be preferred to keep the already
documented isl prefix, even though it doesn't follow
Currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. At this point, changing the vendor
symbol to the most often used variant, which is equal to the
NASDAQ symbol, isil, should not hurt.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Currently there is a wild mixture of isl, isil, and intersil compatibles
in the kernel. At this point, changing the vendor symbol to the most often
used variant, which is equal to the NASDAQ symbol, isil, should not hurt.
Patch 70e123373c05 (rtc: Add support for Intersil ISL12057 I2C RTC chip)
Currently there is a wild mixture of isl, isil, and intersil
compatibles in the kernel. At this point, changing the vendor
symbol to the most often used variant, which is equal to the
NASDAQ symbol, isil, should not hurt.
This patch marks both intersil and isl prefix as deprecated
and documents
Hi Jason,
Am Sonntag, den 07.09.2014, 09:32 -0400 schrieb Jason Cooper:
Just to dot our i's and cross our t's, would you mind sending out a
non-rfc version of this series?
Thank you for the reminder, I have sent an updated version.
regards
Philipp
On 07.09.14 18:31, Madhavan Srinivasan wrote:
This patch adds kernel side support for software breakpoint.
Design is that, by using an illegal instruction, we trap to hypervisor
via Emulation Assistance interrupt, where we check for the illegal instruction
and accordingly we return to Host
On 07.09.14 18:31, Madhavan Srinivasan wrote:
This patch extends the use of illegal instruction as software
breakpoint instruction across the ppc platform. Patch extends
booke program interrupt code to support software breakpoint.
Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com
On Wed, 27 Aug 2014 17:09:39 +0300, Laurentiu Tudor b10...@freescale.com
wrote:
Simply swap of_alias and of_chosen initialization so
that of_alias ends up read first. This must be done
because it is accessed couple of lines below when
trying to initialize the of_stdout using the alias
based
It looks like you have a lot of the same changes as the patch Bharata
sent out last week. Including the one issue I saw in Bharata's patch
below.
On 09/05/2014 02:09 PM, Thomas Falcon wrote:
This patch attempts to ensure that all values are in the proper
endianness format when both hotadding
On 09/08/2014 04:29 PM, Grant Likely wrote:
On Wed, 27 Aug 2014 17:09:39 +0300, Laurentiu Tudor b10...@freescale.com
wrote:
Simply swap of_alias and of_chosen initialization so
that of_alias ends up read first. This must be done
because it is accessed couple of lines below when
trying to
在 2014年9月5日，18:42，Sergei Shtylyov sergei.shtyl...@cogentembedded.com 写道：
Hello.
On 9/5/2014 2:09 PM, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
在 2014年9月5日，18:47，Sergei Shtylyov sergei.shtyl...@cogentembedded.com 写道：
Hello.
On 9/5/2014 2:10 PM, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Signed-off-by: Yijing Wang
Paul E. McKenney wrote:
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in synchronization algorithms. It also documents that
CPUs must provide
I guess we were both working on it independently. I had made the
changes to hotplug a cpu a few weeks ago, but was blocked on removing a
cpu. Last week I realized what was blocking me and fixed cpu removal,
so I sent the patch along. Since Bharata has already submitted a patch
that will
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
Right, because the x86 architecture was obsolete and
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.
On 09/07/2014 10:56 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on all alignment
requiring architectures, like PPC and Sparc as
On Mon, 2014-09-08 at 18:52 +0100, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on
On Mon, 2014-09-08 at 11:12 -0700, H. Peter Anvin wrote:
On 09/07/2014 10:56 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote:
How many PARISC systems do we have that actually do real work on Linux?
I'd be very surprised if this problem didn't exist on
On 09/08/2014 12:09 PM, James Bottomley wrote:
Um, I think you need to re-read the thread; that's not what I said at
all. It's even written lower down: PA can't do atomic bit sets (no
atomic RMW except the ldcw operation) it can do atomic writes to
fundamental sizes (byte, short, int, long)
I think the whole removing Alpha EV5 support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to do byte aligned stores.
Alan
Is *that*
On 09/08/2014 12:09 PM, James Bottomley wrote:
Um, I think you need to re-read the thread; that's not what I said at
all. It's even written lower down: PA can't do atomic bit sets (no
atomic RMW except the ldcw operation) it can do atomic writes to
fundamental sizes (byte, short, int, long)
Tasks get their end of stack set to STACK_END_MAGIC with the
aim to catch stack overruns. Currently this feature does not
apply to init_task. This patch removes this restriction.
Note that a similar patch was posted by Prarit Bhargava [1]
some time ago but was never merged.
[1]:
This facility is used in a few places so let's introduce
a helper function to improve code readability.
Signed-off-by: Aaron Tomlin atom...@redhat.com
---
arch/powerpc/mm/fault.c| 4 +---
arch/x86/mm/fault.c| 4 +---
include/linux/sched.h | 2 ++
kernel/trace/trace_stack.c | 2
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which
Currently in the event of a stack overrun a call to schedule()
does not check for this type of corruption. This corruption is
often silent and can go unnoticed. However once the corrupted
region is examined at a later stage, the outcome is undefined
and often results in a sporadic page fault which
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking code, for instance.
Can you clarify what you think the
On Mon, 2014-09-08 at 16:45 -0400, Chris Metcalf wrote:
On 9/8/2014 1:50 AM, James Bottomley wrote:
Actual alignment is pretty irrelevant. That's why all architectures
which require alignment also have to implement misaligned traps ... this
is a fundamental requirement of the networking
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is a bit ironic because I remember when Digital had a team
working on
On 09/08/2014 01:50 AM, James Bottomley wrote:
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote:
On 09/07/2014 03:04 PM, James Bottomley wrote:
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote:
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote:
On Thu, 2014-09-04
On Friday, September 05, 2014 01:11:22 PM Viresh Kumar wrote:
On 5 September 2014 13:09, Preeti U Murthy pre...@linux.vnet.ibm.com wrote:
Today cpus go to winkle when they are offlined. Since it is the deepest
idle state that we have, it is expected to save good amount of power as
compared
On Fri, 2014-09-05 at 15:27 -0600, Bjorn Helgaas wrote:
On Fri, Sep 5, 2014 at 3:25 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of useless arch_msi_check_device().
I am not
Michael Ellerman m...@ellerman.id.au writes:
The encoding of the lengths in the ibm_architecture_vec array is
interesting to say the least. It's non-obvious how the number of bytes
we provide relates to the length value.
In fact we already got it wrong once, see 11e9ed43ca8a Fix up
On Mon, Sep 08, 2014 at 06:47:35PM -0400, Peter Hurley wrote:
On 09/08/2014 01:59 PM, H. Peter Anvin wrote:
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
On Fri, 05 Sep 2014 08:41:52 -0700
H. Peter Anvin h...@zytor.com wrote:
On 09/05/2014 08:31 AM, Peter Hurley wrote:
Which is
On 2014/9/5 22:29, David Vrabel wrote:
On 05/09/14 11:09, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
[...]
--- a/arch/x86/pci/xen.c
+++ b/arch/x86/pci/xen.c
[...]
@@ -418,9
On 09/08/2014 03:43 PM, James Bottomley wrote:
This was years ago (possibly decades). We had to implement in-kernel
unaligned traps for the networking layer because it could access short
and int fields that weren't of the correct alignment when processing
packets. It that's all corrected
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM, James Bottomley wrote:
Two things: I think that gcc has given up on combining adjacent writes,
perhaps because unaligned writes on some arches are prohibitive, so
whatever minor optimization was believed to be
On 09/08/2014 07:56 PM, James Bottomley wrote:
Yeah, the extra requirement I added is basically nonsense, since the
only issue is what instructions the compiler is emitting. So if compiler
thinks the alignment is natural and combines the writes -- ok. If the
compiler thinks the alignment is
Add a short member for proper alignment and one will probably pop out.
Sent from my tablet, pardon any formatting problems.
On Sep 8, 2014, at 19:56, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Mon, 2014-09-08 at 19:30 -0400, Peter Hurley wrote:
On 09/08/2014 01:50 AM,
43 matches
Mail list logo
