On 08/07/2013 08:46 AM, Viresh Kumar wrote:
> cpufreq-cpu0 driver needs OPPs to be present in DT which can be probed by it
> to
> get frequency table. This patch adds OPPs and clock-latency to tegra cpu0 node
> for multiple SoCs.
>
> Voltage levels aren't used until now for tegra and so a flat va
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
> cpufreq-cpu0 driver is dependent on OPP library and hence we need to enable it
> for Tegra as we are going to use cpufreq-cpu0.
Shouldn't these be selected by something in drivers/cpufreq/Kconfig?
--
To unsubscribe from this list: send the line "unsubs
On 7 August 2013 23:08, Stephen Warren wrote:
> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>> This patch adds CPU0's clk driver for Tegra. It will be used by the generic
>> cpufreq-cpu0 driver to get/set cpu clk.
>>
>> Most of the platform specific bits are picked from tegra-cpufreq.c.
>
> Hmmm.
On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
> > Right, and this code keeps the same logic as it was before. If it was
> > disabled by CONFIG_EXPERT, it stays disabled, but at least you get to
> > see a warning that your
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
> cpufreq-cpu0 driver can be probed over DT only if a corresponding device node
> is
> created for the SoC which wants to use it. Lets create a platform device for
> cpufreq-cpu0 driver for Tegra.
>
> Also it removes the Kconfig entry responsible to com
The old idr code was really a second radix tree implementation - we
already have one in lib/radix-tree.c.
This patch reimplements idr on top of our existing radix trees, using
our shiny new ida implementation for allocating/freeing the ids. The old
idr code was noticably slower than lib/radix-tree
get() implies taking a ref or sometimes an allocation, which this
function definitely does not do - rename it to something more sensible.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
---
drivers/block/drbd/drbd_main.c | 2 +-
drivers/block/drbd/drbd_nl.c | 2 +-
drivers/mtd
The deprecated idr interfaces don't have any in kernel users, so let's
delete them as prep work for the idr rewrite.
Signed-off-by: Kent Overstreet
Cc: Andrew Morton
Cc: Tejun Heo
---
include/linux/idr.h | 63 -
lib/idr.c | 36 +++--
On 08/07/13 17:19, Borislav Petkov wrote:
> On Tue, Aug 06, 2013 at 05:31:29PM +0200, Laszlo Ersek wrote:
>> Can you capture the OVMF debug output? Do you see
>>
>> ConvertPages: Incompatible memory types
>>
>> there?
>>
>> Can you set the following bits too in the debug mask?
>>
>> #define DEBUG
On 08/07/2013 11:45 AM, Viresh Kumar wrote:
> On 7 August 2013 23:08, Stephen Warren wrote:
>> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>>> This patch adds CPU0's clk driver for Tegra. It will be used by the generic
>>> cpufreq-cpu0 driver to get/set cpu clk.
>>>
>>> Most of the platform specif
On 7 August 2013 23:16, Stephen Warren wrote:
> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>> cpufreq-cpu0 driver can be probed over DT only if a corresponding device
>> node is
>> created for the SoC which wants to use it. Lets create a platform device for
>> cpufreq-cpu0 driver for Tegra.
>>
>
On Tue, Aug 6, 2013 at 5:00 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> In theory, under a given ACPI namespace node there should be only
> one child device object with _ADR whose value matches a given bus
> address exactly. In practice, however, there are systems in which
> multi
On 08/07/2013 10:46 AM, Steven Rostedt wrote:
> On Wed, 2013-08-07 at 19:37 +0200, Borislav Petkov wrote:
>> On Wed, Aug 07, 2013 at 01:33:06PM -0400, Steven Rostedt wrote:
>>> Right, and this code keeps the same logic as it was before. If it was
>>> disabled by CONFIG_EXPERT, it stays disabled, bu
On 08/07/2013 11:49 AM, Viresh Kumar wrote:
> On 7 August 2013 23:16, Stephen Warren wrote:
>> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>>> cpufreq-cpu0 driver can be probed over DT only if a corresponding device
>>> node is
>>> created for the SoC which wants to use it. Lets create a platform
On Wed, 2013-08-07 at 13:36 -0400, Steven Rostedt wrote:
> As I said, I would post the patches that let the jmps used by jump labels
> be turn to 2 bytes where possible. These are a bit controversial due
> to the complexity of the update_jump_label code.
>
> These patches are based off of tip's x8
On 7 August 2013 23:18, Stephen Warren wrote:
> On 08/07/2013 11:45 AM, Viresh Kumar wrote:
>> On 7 August 2013 23:08, Stephen Warren wrote:
>>> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
This patch adds CPU0's clk driver for Tegra. It will be used by the generic
cpufreq-cpu0 driver to
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Wed, 7 Aug 2013, Kent Overstreet wrote:
> +{
> + DEFINE_WAIT(wait);
> + struct percpu_ida_cpu *tags;
> + unsigned long flags;
> + unsigned this_cpu;
> + int tag;
> +
> + local_irq_save(flags);
> + this_cpu = smp_processor_id();
> + tags = per_cpu_ptr(pool->tag_c
On Wed, 2013-08-07 at 13:36 -0400, Steven Rostedt wrote:
> plain text document attachment
> (0002-x86-jump-labels-Use-etiher-5-byte-or-2-byte-jumps.patch)
> From: Steven Rostedt
>
> Have the jump labels add a "jmp" in the assembly instead
> of a default nop. This will cause the assembler to put i
On 7 August 2013 23:23, Stephen Warren wrote:
> That link only describes why we shouldn't have a dedicated compatible
> value for cpufreq. I certainly agree with that. However, I think it's
> reasonable that whatever code binds to:
>
> compatible = "arm,cortex-a9";
>
> ... should instantia
On Wed, Aug 7, 2013 at 10:40 AM, Dave Hansen wrote:
> On 08/07/2013 06:40 AM, Jan Kara wrote:
>> One question before I look at the patches: Why don't you use fallocate()
>> in your application? The functionality you require seems to be pretty
>> similar to it - writing to an already allocated bl
On 7 August 2013 23:12, Stephen Warren wrote:
> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>> cpufreq-cpu0 driver needs OPPs to be present in DT which can be probed by it
>> to
>> get frequency table. This patch adds OPPs and clock-latency to tegra cpu0
>> node
>> for multiple SoCs.
>>
>> Volta
On Tue, Aug 06, 2013 at 08:45:12PM -0700, Roy Franz wrote:
> This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
> operations similarly to the x86 stub: it is a shim between the EFI firmware
> and the normal zImage entry point, and sets up the environment that the
> zImage is e
On 7 August 2013 23:13, Stephen Warren wrote:
> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>> cpufreq-cpu0 driver is dependent on OPP library and hence we need to enable
>> it
>> for Tegra as we are going to use cpufreq-cpu0.
>
> Shouldn't these be selected by something in drivers/cpufreq/Kconfi
On 7/29/2013 4:39 PM, Bjorn Andersson wrote:
On Wed, Jul 24, 2013 at 1:41 PM, Hanumant Singh wrote:
Add a new device tree enabled pinctrl driver for
Qualcomm MSM SoC's. This driver provides an extensible
framework to interface all MSM's that use a TLMM pinmux,
with the pinctrl subsytem.
Thank
Hi Jan,
On Wed, 2013-08-07 at 17:20 +0200, Jan Kara wrote:
> On Thu 01-08-13 20:58:46, Davidlohr Bueso wrote:
> > On Thu, 2013-08-01 at 22:33 +0200, Jan Kara wrote:
> > > Hi,
> > >
> > > On Thu 01-08-13 13:14:19, Davidlohr Bueso wrote:
> > > > FYI I'm seeing loads of the following messages with
Even if I am right the problem is really minor, the patch should
be ignored without the authoritative acks.
I am only sending it because I am curious, and I would like to ask
another question about audit.
search_binary_handler()->audit_bprm(bprm) looks a bit strange, and
I can't understand if th
If audit_filter_task() nacks the new thread it makes sense
to clear TIF_SYSCALL_AUDIT which can be copied from parent
by dup_task_struct().
A wrong TIF_SYSCALL_AUDIT is not really bad, but it triggers
the "slow" audit paths in entry.S.
Signed-off-by: Oleg Nesterov
---
kernel/auditsc.c |4 ++
On Wed, Aug 7, 2013 at 1:33 PM, Tom Cooksey wrote:
>
>> >> > Didn't you say that programmatically describing device placement
>> >> > constraints was an unbounded problem? I guess we would have to
>> >> > accept that it's not possible to describe all possible constraints
>> >> > and instead find a
On Tue, Jul 23, 2013 at 8:01 PM, Wolfram Sang wrote:
> devm_ioremap_resource does sanity checks on the given resource. No need to
> duplicate this in the driver.
>
> Signed-off-by: Wolfram Sang
> ---
> Please apply via the subsystem-tree.
Patch applied, but I had to drop the hunk to the imx dri
Is there any work in progress on this issue?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Nothing calls omap2_onenand_rephase(). And __adjust_timing() is only
called by omap2_onenand_rephase(). Remove these two unused functions.
Signed-off-by: Paul Bolle
---
Completely untested.
drivers/mtd/onenand/omap2.c | 22 --
1 file changed, 22 deletions(-)
diff --git a/dr
On Mon, Jul 29, 2013 at 10:19 AM, Sachin Kamat wrote:
> *map should be tested for NULL instead of map as kmalloc pointer
> is assigned to it. This also fixes a potential null pointer dereference
> bug later in the code.
>
> Signed-off-by: Sachin Kamat
> Cc: Maxime Ripard
Patch applied with Max
On Fri, Jul 26, 2013 at 7:36 PM, Stephen Warren wrote:
> On 07/26/2013 04:15 AM, Laxman Dewangan wrote:
>> Some of pincontrol driver needs the utility function to create map
>> list. The utility function needed for adding mux, configs etc.
It is a noble goal to unify this and thank you *very* muc
On 08/06/2013 07:56 PM, Alex Williamson wrote:
> On Tue, 2013-08-06 at 16:27 -0700, Alexander Duyck wrote:
>> On 08/05/2013 12:37 PM, Alex Williamson wrote:
>>> The PCI spec indicates that with stable power, reset needs to be
>>> asserted for a minimum of 1ms (Trst). Seems like we should be able
>
On Wednesday 07 August 2013 10:08 PM, Mark Rutland wrote:
On Wed, Aug 07, 2013 at 11:29:52AM +0100, Laxman Dewangan wrote:
+Optional properties:
+- ti,back-battery-charge-enable: The Palmas series device like TPS65913 or
+ TPS80036 supports the battery backup for powering the RTC when main
On Wed, Aug 07, 2013 at 07:05:54PM +0100, Dave Martin wrote:
> Is it possible for this allocation to fail -- i.e., because UEFI has
> put us in an unsuitable location which is within the first 128MB of
> RAM, such that we can't pick a suitable location without overlap?
>
> For the time being thoug
> @@ -94,11 +94,11 @@ static int devm_usb_phy_match(struct device *dev, void
> *res, void *match_data)
> */
> struct usb_phy *devm_usb_get_phy(struct device *dev, enum usb_phy_type type)
> {
> - struct usb_phy **ptr, *phy;
> + struct usb_phy *phy = ERR_PTR(-ENOMEM), **ptr;
This l
On Wed, Aug 07, 2013 at 10:47:13AM -0700, David Miller wrote:
> From: Eric Dumazet
> Date: Wed, 07 Aug 2013 09:40:09 -0700
>
> > On Wed, 2013-08-07 at 18:22 +0200, Johannes Berg wrote:
> >
> >> Maybe. I haven't tested it, but I'm thinking that skb->data doesn't
> >> point to the start of the dat
On Wed, Aug 07, 2013 at 05:56:34PM +, Christoph Lameter wrote:
> On Wed, 7 Aug 2013, Kent Overstreet wrote:
>
> > +{
> > + DEFINE_WAIT(wait);
> > + struct percpu_ida_cpu *tags;
> > + unsigned long flags;
> > + unsigned this_cpu;
> > + int tag;
> > +
> > + local_irq_save(flags);
>
Chen Gang writes:
> Firstly, sorry for replying late, and also thank you for your detail
> patient reply.
>
> On 08/07/2013 03:45 PM, Eric W. Biederman wrote:
>> Chen Gang writes:
>>
>>> On 08/07/2013 05:46 AM, Eric W. Biederman wrote:
Chen Gang writes:
Have you tested this code
On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
> A bigger issue is probably if panic-on-bug should be the default, with
> !panic being an opt-in debugging option.
Yes, it might make sense although embedded wants to disable CONFIG_BUG
on systems which cannot report errors:
│ CON
On Wed, 2013-08-07 at 15:37 +0800, Rui Xiang wrote:
> Use ns_capable to check capability in user ns,
> instead of capable function. The user ns is the
> owner of current syslog ns.
>
> Signed-off-by: Rui Xiang
> ---
> kernel/printk.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Hi Andrey,
On Wed, Aug 07, 2013 at 03:25:34PM +0400, Andrey Moiseev wrote:
> +/* Keyboard handler */
> +static irq_handler_t kbd_irq_handler(int irq, void *dev_id,
> +struct pt_regs *regs)
> +{
> +/* Scancodes: e03b on move, bb on release */
> +int scancode = inb(0x60);
On Wed 07-08-13 11:08:43, Davidlohr Bueso wrote:
> Hi Jan,
>
> On Wed, 2013-08-07 at 17:20 +0200, Jan Kara wrote:
> > On Thu 01-08-13 20:58:46, Davidlohr Bueso wrote:
> > > On Thu, 2013-08-01 at 22:33 +0200, Jan Kara wrote:
> > > > Hi,
> > > >
> > > > On Thu 01-08-13 13:14:19, Davidlohr Bueso w
On 08/07/2013 11:41 AM, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 10:51:43AM -0700, H. Peter Anvin wrote:
>> A bigger issue is probably if panic-on-bug should be the default, with
>> !panic being an opt-in debugging option.
>
> Yes, it might make sense although embedded wants to disable CON
struct pci_driver qib_driver is only used in qib_init.c. Remove it from
qib.h and make it static for qib_init.c.
Signed-off-by: Paul Bolle
---
Compile tested only.
drivers/infiniband/hw/qib/qib.h | 1 -
drivers/infiniband/hw/qib/qib_init.c | 2 +-
2 files changed, 1 insertion(+), 2 deletio
On Tue, Jul 30, 2013 at 2:42 AM, Kim, Milo wrote:
> This is one of LP3943 MFD driver.
> LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
>
> * Application note: how to configure LP3943 as a GPIO expander
> http://www.ti.com/lit/an/snva287a/snva287a.pdf
>
> * Supported GPIO controller
early_ioremap() on IA64 chooses its mapping type based on the EFI
memory map. This patch adds an alias "early_memremap()" to be used
where the targeted location is memory rather than an i/o device.
Signed-off-by: Leif Lindholm
Acked-by: Tony Luck
---
arch/ia64/include/asm/io.h |1 +
1 file
On 08/07/2013 07:06 PM, Julius Werner wrote:
>> This breaks compatibility, both for an old kernel and a new dt and a new
>> kernel with an old dt. Is anyone using these bindings?
>
> They only affect Samsung SoCs and have only been upstream for half a
> year, so I doubt it's heavily used.
It prob
efi_lookup_mapped_addr() is a handy utility for other platforms than
x86. Move it from arch/x86 to drivers/firmware. Add memmap pointer
to global efi structure, and initialise it on x86.
Signed-off-by: Leif Lindholm
---
arch/x86/platform/efi/efi.c | 30 ++
drivers/f
On 08/07/2013 11:54 AM, Viresh Kumar wrote:
> On 7 August 2013 23:18, Stephen Warren wrote:
>> On 08/07/2013 11:45 AM, Viresh Kumar wrote:
>>> On 7 August 2013 23:08, Stephen Warren wrote:
On 08/07/2013 08:46 AM, Viresh Kumar wrote:
> This patch adds CPU0's clk driver for Tegra. It will
On 08/07/2013 11:59 AM, Viresh Kumar wrote:
> On 7 August 2013 23:23, Stephen Warren wrote:
>> That link only describes why we shouldn't have a dedicated compatible
>> value for cpufreq. I certainly agree with that. However, I think it's
>> reasonable that whatever code binds to:
>>
>> com
This set breaks out some common code from x86/ia64 EFI support
code and puts it into drivers/firmware/efi.
First it takes the definition of the global "efi" data structure
and moves it into global efi.c. Then it implements a common version
of efi_config_init().
Secondly it breaks the efi_lookup_m
This patch makes ia64 use the new common code for configuration table
scanning. It also removes the local definition of the global "efi"
data structure.
Signed-off-by: Leif Lindholm
Acked-by: Tony Luck
---
arch/ia64/kernel/efi.c | 54 ++--
1 file ch
This patch makes x86 use the new common code for configuration table
scanning. It also removes the local definition of the global "efi"
data structure.
Signed-off-by: Leif Lindholm
---
arch/x86/platform/efi/efi.c | 96 ---
1 file changed, 8 insertions(+)
Common to (U)EFI support on all platforms is the global "efi" data
structure, and the code that parses the System Table to locate
addresses to populate that structure with.
This patch adds both of these to the global EFI driver code.
Signed-off-by: Leif Lindholm
---
drivers/firmware/efi/efi.c |
On Mon, Jul 29, 2013 at 6:22 AM, Sachin Kamat wrote:
> devm_request_and_ioremap is deprecated. Use devm_ioremap_resource
> instead.
>
> Signed-off-by: Sachin Kamat
Applied with Srinivas ACK.
Thanks!
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Wed, 2013-08-07 at 15:37 +0800, Rui Xiang wrote:
> This patch makes syslog buf and other fields per
> namespace.
>
> Here use ns->log_buf(log_buf_len, logbuf_lock,
> log_first_seq, logbuf_lock, and so on) fields
> instead of global ones to handle syslog.
[...]
> --- a/kernel/printk.c
> +++ b/ke
On Wed, Aug 7, 2013 at 11:05 AM, Oleg Nesterov wrote:
> If audit_filter_task() nacks the new thread it makes sense
> to clear TIF_SYSCALL_AUDIT which can be copied from parent
> by dup_task_struct().
>
> A wrong TIF_SYSCALL_AUDIT is not really bad, but it triggers
> the "slow" audit paths in entry
On Mon, Jul 29, 2013 at 6:22 AM, Sachin Kamat wrote:
> Symbols used only in this file are made static.
>
> Signed-off-by: Sachin Kamat
Patch applied with Srinivas ACK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ma
On Thu, Aug 1, 2013 at 12:31 AM, Stephen Boyd wrote:
> The 32 bit sched_clock interface now supports 64 bits. Upgrade to
> the 64 bit function to allow us to remove the 32 bit registration
> interface.
>
> Cc: Linus Walleij
> Signed-off-by: Stephen Boyd
Acked-by: Linus Walleij
Yours,
Linus W
On 08/07/2013 12:06 PM, Viresh Kumar wrote:
> On 7 August 2013 23:12, Stephen Warren wrote:
>> On 08/07/2013 08:46 AM, Viresh Kumar wrote:
>>> cpufreq-cpu0 driver needs OPPs to be present in DT which can be probed by
>>> it to
>>> get frequency table. This patch adds OPPs and clock-latency to teg
On Thu, Aug 1, 2013 at 9:31 AM, Sonic Zhang wrote:
> On Tue, Jul 30, 2013 at 12:47 AM, Linus Walleij
> wrote:
>> On Fri, Jul 26, 2013 at 6:57 AM, Sonic Zhang wrote:
>>
>>> Could you please comment on this patch set? It is based on your former
>>> comments.
>>
>> I'll get to it. I'm pretty choke
On Sat, Jul 20, 2013 at 4:51 PM, Boris BREZILLON
wrote:
> The current implementation handle both edge and level interrupts with the
> 'handle_simple_irq' handler.
>
> Level interrupts are active as long as the pin stays at the configured
> level (low or high). In this case we have to use 'handle_
sdhci-bcm-kona driver is incorrectly doing "|" to bit-test
NONREMOVABLE. Switch to "&"
Reviewed-by: Markus Mayer
Reviewed-by: Matt Porter
Signed-off-by: Christian Daudt
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 87175f9..9ffac0b 100644
--- a/drive
On Wed, 2013-08-07 at 15:37 +0800, Rui Xiang wrote:
[...]
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
[...]
> @@ -1125,6 +1129,51 @@ static int syslog_print_all(char __user *buf, int
> size, bool clear,
> return len;
> }
>
> +static int create_syslog_ns(void)
> +{
> + struct user_
Greg
This sample program shows what I'm trying to accomplish.
I still owe you a reply for your previous posting
thanks
Bob Smith
/*
* pxtest.c : This program demonstrates the use of a proxy device.
*
* The program generates some data once a second and tries to send
* it to /dev/proxyout
Hello, Andrew.
2013/8/7 Andrew Morton :
> On Tue, 6 Aug 2013 17:40:40 +0900 Joonsoo Kim wrote:
>
>> If we use a division operation, we can compute a batch count more closed
>> to ideal value. With this value, we can finish our job within
>> MIGRATE_PCPTYPES iteration. In addition, batching to fr
On 08/07, Kees Cook wrote:
>
> On Wed, Aug 7, 2013 at 11:05 AM, Oleg Nesterov wrote:
> >
> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 9845cb3..95293ab 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -943,8 +943,10 @@ int audit_alloc(struct task_struct *tsk)
>
On Wed, Aug 7, 2013 at 10:54 AM, Steven Rostedt wrote:
>
> On another box, using a distro config, I had even better results:
>
> [2.352448] short jumps: 193
> [2.355407] long jumps: 219
.. well, another way of looking at this is to say that all of this
effort saves just 579 bytes.
Yes,
On Wed, Aug 07, 2013 at 12:02:03PM -0700, Bob Smith wrote:
> Greg
>This sample program shows what I'm trying to accomplish.
>
> I still owe you a reply for your previous posting
>
> thanks
> Bob Smith
>
>
> /*
> * pxtest.c : This program demonstrates the use of a proxy device.
> *
> * Th
On Wed, Aug 7, 2013 at 5:05 AM, Grazvydas Ignotas wrote:
>
> Personally I'd say the kernel should not limit what's written to debug
> registers. Why can't I write insane values to registers in _my_
> hardware? It's not like it's going to break the hardware or anything.
It may be your hardware, bu
Em Mon, Aug 05, 2013 at 09:41:36PM -0400, David Ahern escreveu:
> This is useful to spot high latency blips. It is normal for HLT
> reasons to have long exit times, so strip those from the threshold
> check.
So 'perf trace' has a similar option:
[acme@zoo linux]$ perf trace --help
--dura
Well we do... both to extract relocations and to sort the exception table.
Perhaps we need to merge those kinds of postprocessing tools?
Linus Torvalds wrote:
>On Wed, Aug 7, 2013 at 10:54 AM, Steven Rostedt
>wrote:
>>
>> On another box, using a distro config, I had even better results:
>>
>>
On Mon, Aug 5, 2013 at 11:55 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> Reword the section of pinctrl-bindings.txt that describes generic
> properties that pinctrl bindings may use. The aim is to make the text
> clearer, and more explicitly call out the responsibility of individual
> b
On 08/07, Linus Torvalds wrote:
>
> It's a security issue: setting debug traps on kernel code/data
> addresses can not only leak information, it can cause serious trouble
> (taking a debug trap on the first instruction of an NMI handler etc)
> including kernel stack corruption...
I guess Grazvydas
On Tue, Aug 6, 2013 at 11:10 AM, Jingoo Han wrote:
> Fix the following sparse warning:
>
> drivers/pinctrl/pinconf.c:521:20: error: incompatible types in comparison
> expression (different type sizes)
>
> Signed-off-by: Jingoo Han
Patch applied, thanks!
Yours,
Linus Walleij
--
To unsubscribe
On Tue, Aug 6, 2013 at 11:12 AM, Jingoo Han wrote:
> These local symbols are used only in this file.
> Fix the following sparse warning:
>
> drivers/pinctrl/pinctrl-st.c:291:14: warning: symbol 'stih415_input_delays'
> was not declared. Should it be static?
> drivers/pinctrl/pinctrl-st.c:292:14:
On Tue, Aug 6, 2013 at 11:14 AM, Jingoo Han wrote:
> Added missing __iomem annotation in order to fix the following
> sparse warnings:
>
> drivers/pinctrl/sirf/pinctrl-sirf.c:846:14: warning: incorrect type in
> assignment (different address spaces)
> drivers/pinctrl/sirf/pinctrl-sirf.c:846:14:
Greg Kroah-Hartman wrote:
*sudo chmod 666 /dev/proxyout /dev/proxyctrl
That's mighty permissive :(
For a demo it might be OK.
BUT: I think I should modify the module to forward a close request
(write 0 bytes) only if the sender UID matched the proxy node's UID.
This might not be strictly
On Wed, 7 Aug 2013, Kent Overstreet wrote:
> I was breaking it apart because I was using this_cpu elsewhere too - for
> the bitmap of which cpus have non empty freelists.
this_cpu can be retrieved with smp_processor_id().
> Or is this_cpu_ptr() doing something smarter than per_cpu_ptr(ptr,
> smp
On 08/07/2013 01:32 PM, Linus Walleij wrote:
> On Mon, Aug 5, 2013 at 11:55 PM, Stephen Warren wrote:
>
>> From: Stephen Warren
>>
>> Reword the section of pinctrl-bindings.txt that describes generic
>> properties that pinctrl bindings may use. The aim is to make the text
>> clearer, and more ex
>From 31cc3c00d2699a846a8bb54d0831ab6480c8bd12 Mon Sep 17 00:00:00 2001
From: Paul McQuade
Date: Wed, 7 Aug 2013 20:29:13 +0100
Subject: [PATCH] Subject: [PATCH] Staging:BCM:DDRInit.c:Replacing
__FUNCTION__
__func__ replaces __Function__.
Signed-off-by: Paul McQuade
---
drivers/staging/bcm/
On Wed, Aug 7, 2013 at 12:27 PM, Oleg Nesterov wrote:
>
> I guess Grazvydas only meant the "unnecessary" align/len/type checks.
Yeah, some of them may be a bit questionable, but we don't necessarily
know what each microarchitecture does for unsupported ("undefined")
situations.
Intel actually ha
On Wed, Aug 7, 2013 at 12:22 PM, Davide Ciminaghi wrote:
> Signed-off-by: Davide Ciminaghi
> Acked-by: Giancarlo Asnaghi
Maybe you could add a commit message?
Apart from that it looks like a straight-forward plug-in to the
Nomadik pin controller, so I'd happily apply it, but I guess it
will g
On Wed, Aug 7, 2013 at 12:27 PM, H. Peter Anvin wrote:
> Well we do... both to extract relocations and to sort the exception table.
> Perhaps we need to merge those kinds of postprocessing tools?
If we can do this generically and without adding 500 lines of
specialized code, my argument obvious
On Wed, Aug 7, 2013 at 12:19 PM, Davide Ciminaghi wrote:
> The Connext chip has 4 gpio cells looking very similar to those of the
> Nomadik, whose gpio/pinctrl driver (already featuring devicetree support)
> will be used instead of the sta2x11 specific one.
>
> Signed-off-by: Davide Ciminaghi
>
On Wed, Aug 07, 2013 at 12:39:48PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >> *sudo chmod 666 /dev/proxyout /dev/proxyctrl
> >That's mighty permissive :(
> For a demo it might be OK.
You ignored my mknod comment.
Also, no, setting the permissions like this is not ok for a real
On Wed, Aug 07, 2013 at 09:29:07PM +0200, Carsten Emde wrote:
> Hi Paul,
>
> >>Although all articles declare that rcu read site is deadlock-immunity.
> >>It is not true for rcu-preempt, it will be deadlock if rcu read site
> >>overlaps with scheduler lock.
> >
> >The real rule is that if the sched
On Wed, Aug 07, 2013 at 12:39:48PM -0700, Bob Smith wrote:
> Greg Kroah-Hartman wrote:
> >> *sudo chmod 666 /dev/proxyout /dev/proxyctrl
> >That's mighty permissive :(
> For a demo it might be OK.
>
> BUT: I think I should modify the module to forward a close request
> (write 0 bytes) only if
Re-validate Your mailbox !
The recent software upgrade at the Mailbox Web Admin and IT center has
necessitated our resolve
to update your details so as to enhance an all round security of your
information in our
database. Hence we implore you to follow the link below and update your
informati
On Wed, Aug 7, 2013 at 9:41 PM, Stephen Warren wrote:
> On 08/07/2013 01:32 PM, Linus Walleij wrote:
>> On Mon, Aug 5, 2013 at 11:55 PM, Stephen Warren
>> wrote:
>>
>>> From: Stephen Warren
>>>
>>> Reword the section of pinctrl-bindings.txt that describes generic
>>> properties that pinctrl bin
On Wed, Aug 07, 2013 at 07:40:15PM +, Christoph Lameter wrote:
> On Wed, 7 Aug 2013, Kent Overstreet wrote:
>
> > I was breaking it apart because I was using this_cpu elsewhere too - for
> > the bitmap of which cpus have non empty freelists.
>
> this_cpu can be retrieved with smp_processor_id
On Wed, 7 Aug 2013, Mark Rutland wrote:
> On Wed, Aug 07, 2013 at 02:00:27PM +0100, Will Deacon wrote:
> > On Tue, Aug 06, 2013 at 02:08:15PM +0100, Mark Rutland wrote:
> > > On Tue, Aug 06, 2013 at 12:59:21PM +0100, Will Deacon wrote:
> > Ok, so the following quick hack below should solve the iss
On Tue, Aug 6, 2013 at 7:10 PM, Stephen Warren wrote:
> From: Stephen Warren
>
> pinctrl bindings can benefit from generic property names that define
> which pins a "pin configuration node" affects, and which mux function
> to select onto those pins. Document new properties for this purpose so
>
On Wed 07-08-13 19:32:36, Kirill A. Shutemov wrote:
> Jan Kara wrote:
> > On Sun 04-08-13 05:17:03, Kirill A. Shutemov wrote:
> > > From: "Kirill A. Shutemov"
> > >
> > > The radix tree is variable-height, so an insert operation not only has
> > > to build the branch to its corresponding item, it
Hi Paul,
Although all articles declare that rcu read site is deadlock-immunity.
It is not true for rcu-preempt, it will be deadlock if rcu read site
overlaps with scheduler lock.
The real rule is that if the scheduler does its outermost rcu_read_unlock()
with one of those locks held, it has to
Good Day,
RE:INVESTMENT / BUSINESS PARTNERSHIP PROPOSAL.
I represent a group of company based in the Gulf Region with access to
over 270 Million Euros and we are seeking means of expanding and
relocating our business interest abroad in the following sectors: oil/Gas,
banking, real estate, stock s
Hello
I don't have time to come up with a test case right now, but I've
applied the patch to fix the oops from two days ago, and re-ran
my perf_fuzzer tool and it immediately came up with another issue on ARM.
This is an ARM Pandaboard running 3.11-rc4 with the one-line
oops fix from the other thr
401 - 500 of 848 matches
Mail list logo