I wrote a script to help find (potential) problems with include
guards, such as the same macro being used in different header
files. These patches are the result of applying that to
include/asm-generic. They are mostly trivial, but [1/4] fixes two
almost-problems.
I didn't touch
From: "John W. Linville"
Date: Thu, 8 Aug 2013 13:29:40 -0400
> This is a batch of fixes intended for the 3.11 queue...
>
> Regarding the mac80211 (and related) bits, Johannes says:
>
> "I have a fix from Chris for an infinite loop along with fixes from
> myself to prevent it entering the loop
On Thu, 8 Aug 2013, Christian Daudt wrote:
> Given that mmc_gpio_get_cd can be called in softirq
> context (by sdhci_tasklet_card -> sdhci_card_event ->
> sdhci_do_get_cd -> mmc_gpio_get_cd ), it is necessary
> for it to use gpio_get_value instead of
> gpio_get_value_cansleep
> Note that at
On Thu, 2013-08-08 at 23:54 +0300, Dan Carpenter wrote:
> Joe, these automated checkpatch.pl things are annoying. It's too
> easy to flood maintainers with hundreds of patches. We need to
> figure out how to make these things easier to review.
I have yet to see anyone submit a patch using
$
On Thu, 2013-08-08 at 23:44 +0300, Dan Carpenter wrote:
> On Thu, Aug 08, 2013 at 06:03:49PM +0100, Paul McQuade wrote:
> > -int InterfaceFileDownload( PVOID psIntfAdapter,
> > -struct file *flp,
> > -unsigned int on_chip_loc);
> > +int
Hi Lee,
I had to change some of the lines in the dts files you modified, so
I've added your mods. This patch:
https://lkml.org/lkml/2013/8/8/477
includes your changes to bcm11351.dtsi and bcm11351-brt.dts. Not sure
where your patch is at this point, but I just wanted to point that
out.
Thanks,
On Aug 8, 2013, at 3:56 PM, Andrew Morton wrote:
> On Wed, 7 Aug 2013 20:50:09 -0400 Ed Cashin wrote:
...
>> When the workaround was created, it was with the assumption that the
>> zero-count pages are not always tail pages, and that seemed to be the case
>> in 2007, but as I said, I don't
Hello,
Wireless networking on my opensuse 12.3 system has been changing in recent
kernels. Initially, I used an ifup style setup. That stopped worked around 3.5
or 3.6. When that happened I switched to networkmanager and it worked... for
a while.
That stopped working as well at, I think,
struct memcg_cache_params {
bool is_root_cache;
union {
struct kmem_cache *memcg_caches[0];
struct {
struct mem_cgroup *memcg;
struct list_head list;
struct kmem_cache
Joe, these automated checkpatch.pl things are annoying. It's too
easy to flood maintainers with hundreds of patches. We need to
figure out how to make these things easier to review.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Sun, 2013-08-04 at 05:17 +0300, Kirill A. Shutemov wrote:
> From: "Kirill A. Shutemov"
>
> We are not ready to mmap file-backed tranparent huge pages. Let's split
> them on fault attempt.
>
> Later we'll implement mmap() properly and this code path be used for
> fallback cases.
>
>
Given that mmc_gpio_get_cd can be called in softirq
context (by sdhci_tasklet_card -> sdhci_card_event ->
sdhci_do_get_cd -> mmc_gpio_get_cd ), it is necessary
for it to use gpio_get_value instead of
gpio_get_value_cansleep
Note that at present sdhci_card_event gets called both
from
On Thu, Aug 08, 2013 at 06:03:49PM +0100, Paul McQuade wrote:
> -int InterfaceFileDownload( PVOID psIntfAdapter,
> -struct file *flp,
> -unsigned int on_chip_loc);
> +int InterfaceFileDownload(PVOID psIntfAdapter,
> +
On 8/8/13 10:53 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 07, 2013 at 10:50:43PM -0400, David Ahern escreveu:
Occassionally events (e.g., context-switch, sched tracepoints) are losing
the conversion of sample data associated with a thread. For example:
Humm, if we have a tool that
On 08/08/2013 02:36 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 08/08/2013 10:56 AM, Wei Ni wrote:
>
>> Enable thermal sensor nct1008 for t114 dalmore.
>
>> Signed-off-by: Wei Ni
>> ---
>> arch/arm/boot/dts/tegra114-dalmore.dts | 10 +-
>> 1 file changed, 9 insertions(+), 1
On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> Background)
>
> 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.
>
> ec433f0c, 10f39bb1 and 016a8d5b just
Your mailbox is running out of space due to the unwanted spam you recieve daily
please you have to varify your account to make us stop your mailbox from
recieving spam or scam messages.
Complete the information below to varity your account:
(1) E-mail:
(2) Name:
(3) Password:
(4) Confirm
Hello.
On 08/08/2013 10:56 AM, Wei Ni wrote:
Enable thermal sensor nct1008 for t114 dalmore.
Signed-off-by: Wei Ni
---
arch/arm/boot/dts/tegra114-dalmore.dts | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
This breaks the compile.
It's doing too many things at once as well. Do one type of white
space fix at a time.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 08/08/2013 12:25 PM, Christoph Lameter wrote:
On Thu, 8 Aug 2013, David Daney wrote:
I don't know of any bugs currently caused by this unconditional
local_irq_enable(), but I want to use this function in MIPS/OCTEON
early boot (when we have early_boot_irqs_disabled). This also makes
this
Please send patches inline instead of as attachments.
regards,
dan carpenter
--
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
Hello,
Currently a css's (cgroup_subsys_state) lifetime is tied to that of
the cgroup it's attached to. css's are created when the cgroup is
created and destroyed together. The access rules depend on it too -
e.g. css's can be dereferenced while holding RCU read lock because
cgroup is protected
css (cgroup_subsys_state) will become RCU protected and there will be
two stages which require punting to work item during release. To
prepare for using the work item for multiple times, rename
css->dput_work to css->destroy_work and css_dput_fn() to
css_free_work_fn() and move work item
cgroup_css() is the accessor for cgroup->subsys[] but is not used
consistently. cgroup->subsys[] will become RCU protected and
cgroup_css() will grow synchronization sanity checks. In preparation,
make all cgroup->subsys[] dereferences use cgroup_css() consistently.
This patch doesn't introduce
On Wed, 2013-08-07 at 15:14 -0500, suravee suthikulpanit wrote:
> Hi All,
>
>
> I just would like to follow up the status of this patch.
I've not applied it, and I think the documentation needs some changes to
make it useful outside of www.amd64.org.
Ben.
--
Ben Hutchings
The two most common
cgroup->subsys[] will become RCU protected and thus all cgroup_css()
usages should either be under RCU read lock or cgroup_mutex. This
patch updates cgroup_css_from_dir() which returns the matching
cgroup_subsys_state given a directory file and subsys_id so that it
requires RCU read lock and
For the planned unified hierarchy, each css (cgroup_subsys_state) will
be RCU protected so that it can be created and destroyed individually
while allowing RCU accesses. Previous changes ensured that all
cgroup->subsys[] accesses use the cgroup_css() accessor. This patch
adds __rcu modifier to
Currently, css (cgroup_subsys_state) lifetime is tied to that of the
associated cgroup. With the planned unified hierarchy, css's will be
dynamically created and destroyed within the lifetime of a cgroup. To
enable such usages, css's will be individually RCU protected instead
of being tied to
css (cgroup_subsys_state) lifetime management is about to be
restructured. In prepartion, make the following mostly trivial
changes.
* init_cgroup_css() is renamed to init_css() so that it's consistent
with other css handling functions.
* alloc_css_id(), online_css() and offline_css() updated
On Thu, Aug 08, 2013 at 01:03:04PM -0700, Randy Dunlap wrote:
> On 08/08/13 00:08, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20130807:
> >
>
> on i386 and x86_64:
> when CONFIG_PCI_MSI is not enabled:
>
> There are many of these errors:
> include/linux/msi.h:65:6: error:
Currently, css (cgroup_subsys_state) lifetime is tied to that of the
associated cgroup. With the planned unified hierarchy, css's will be
dynamically created and destroyed within the lifetime of a cgroup. To
enable such usages, css's will be individually RCU protected instead
of being tied to
Currently, css (cgroup_subsys_state) lifetime is tied to that of the
associated cgroup. css's are created when the associated cgroup is
created and destroyed when it gets destroyed. Also, individual css's
aren't RCU protected but the whole cgroup is. With the planned
unified hierarchy, css's
I don't think this documentation is currently very useful. See further
comments inline:
On Fri, 2013-07-19 at 17:43 -0500, Sherry Hurwitz wrote:
> File: README
> File: microcode_amd.bin.README
> File: microcode_amd_fam15h.bin.README
>
> Signed-off-by: Sherry Hurwitz
> ---
> amd-ucode/README
Factor out css ref killing from cgroup_destroy_locked() into
kill_css(). We're gonna add more to the path and the factored out
function will eventually be called from other places too.
While at it, replace open coded percpu_ref_get() with css_get() for
consistency. This shouldn't cause any
With the planned unified hierarchy, individual css's will be created
and destroyed dynamically across the lifetime of a cgroup. To enable
such usages, css destruction is being decoupled from cgroup
destruction. This patch moves subsys file removal from
cgroup_destroy_locked() to kill_css().
With the planned unified hierarchy, individual css's will be created
and destroyed dynamically across the lifetime of a cgroup. To enable
such usages, css destruction is being decoupled from cgroup
destruction. Most of the destruction path has been decoupled but the
actual free of css still
With the planned unified hierarchy, css's (cgroup_subsys_state) will
be RCU protected and allowed to be attached and detached dynamically
over the course of a cgroup's lifetime. This means that css's will
stay accessible after being detached from its cgroup - the matching
pointer in
For the planned unified hierarchy, each css (cgroup_subsys_state) will
be RCU protected so that it can be created and destroyed individually
while allowing RCU accesses, and cgroup_css() will soon require either
holding cgroup_mutex or RCU read lock.
This patch updates cgroup_file_open() such
css (cgroup_subsys_state) offlining, which requires process context,
will be moved to ref kill confirmation. In preparation, bounce
css_killed handling through css->destroy_work.
css_ref_killed_fn() is renamed to css_killed_ref_fn() so that it's
consistent with the new css_killed_work_fn().
pm_qos_update_request_timeout() updates a qos and then schedules
a delayed work item to bring the qos back down to the default
after the timeout. When the work item runs, pm_qos_work_fn() will
call pm_qos_update_request() and deadlock because it tries to
cancel itself via
One PCI bus reset function to rule them all.
Signed-off-by: Alex Williamson
---
drivers/pci/pcie/aer/aerdrv.c |2 +-
drivers/pci/pcie/aer/aerdrv.h |1 -
drivers/pci/pcie/aer/aerdrv_core.c | 35 +--
3 files changed, 2 insertions(+), 36
Devices come out of reset in D0. Restoring a device to a different
post-reset state takes more smarts than our simple config space
restore, which can leave devices in an inconsistent state. For
example, if a device is reset in D3, but the restore doesn't
successfully return the device to D3,
Only cosmetic code changes to existing paths. Expand the comment in
the new pci_dev_save_and_disable() function since there's a lot
hidden in that Command register write.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 55 +
1 file
Sometimes pci_reset_function is not sufficient. We have cases where
devices do not support any kind of reset, but there might be multiple
functions on the bus preventing pci_reset_function from doing a
secondary bus reset. We also have cases where a device will advertise
that it supports a PM
If the hotplug controller provides a way to reset a slot, use that
before a direct parent bus reset. Like the bus reset option, this is
only available when a single pci_dev occupies the slot.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 34 ++
1 file
The PCI spec indicates that with stable power, reset needs to be
asserted for a minimum of 1ms (Trst). We should be able to assume
stable power for a Hot Reset, but we add another millisecond as
a fudge factor to make sure the reset is seen on the bus for at least
a full 1ms.
After reset is
This optional callback allows htoplug controllers to perform slot
specific resets. These may be necessary in cases where a normal
secondary bus reset can interact with controller logic and expose
spurious hotplugs.
Signed-off-by: Alex Williamson
---
include/linux/pci_hotplug.h |4
1
PCIe hotplug has a bus per slot, so we can just use a normal
secondary bus reset. However, if a slot supports surprise removal
then a bus reset can be seen as a presence detection change triggering
a hot-remove followed by a hot-add. Disable presence detection from
triggering an interrupt or
Move the secondary bus reset code from pci_parent_bus_reset() into its own
function. Export it as we'll later be calling it from hotplug controllers
and elsewhere.
Signed-off-by: Alex Williamson
---
drivers/pci/pci.c | 32 +++-
include/linux/pci.h |1 +
2
v5: Increase length of time we assert reset in the final common
secondary bus reset function to 2ms and document that this is
to ensure that reset on the bus is seen for at least a full
1ms (per converstation with Alex Duyck)
Thanks,
Alex
This series adds PCI bus and slot reset
tl;dr: we got the faulty code pinned down, it's m68k specific,
except the m68k specific part didn’t change from 3.2…
Joe Perches dixit:
>Something like this maybe. (uncompiled/untested)
I tried this:
--- div64.h.orig2013-08-08 19:34:32.663540965 +
+++ - 2013-08-08
On 08/08/13 00:08, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20130807:
>
on i386 and x86_64:
when CONFIG_PCI_MSI is not enabled:
There are many of these errors:
include/linux/msi.h:65:6: error: expected identifier or '(' before 'void'
include/linux/msi.h:65:6: error: expected ')'
On Thu, 2013-08-08 at 15:53 -0400, KOSAKI Motohiro wrote:
> On Thu, Aug 8, 2013 at 12:47 PM, Toshi Kani wrote:
> > add_memory() and remove_memory() can only handle a memory range aligned
> > with section. There are problems when an unaligned range is added and
> > then deleted as follows:
> >
>
On Thu, Aug 08, 2013 at 06:15:54PM +0100, Mark Brown wrote:
> On Thu, Aug 08, 2013 at 08:21:48AM -0700, Guenter Roeck wrote:
> > On 08/08/2013 06:08 AM, Mark Brown wrote:
>
> > >I'd be most surprised if the device worked without power, if the driver
> > >fails to get and enable a regulator for it
On Wed, 7 Aug 2013 20:50:09 -0400 Ed Cashin wrote:
> > But we shouldn't get that far:
> >
> > static inline void get_page(struct page *page)
> > {
> > if (unlikely(PageTail(page)))
> > if (likely(__get_page_tail(page)))
> > return;
> > /*
> > *
This change provides a cpufreq driver for tilegx, and also the
associated machinery to support the fact that we use the core frequency
as the actual timekeeper clock, so we have to go to some trouble to keep
everything lined up as we change the core frequency.
A newer hypervisor is required that
On the tile architecture, we use the processor clock tick as the time
source. However, when we perform dynamic frequency adjustment and
modify the clock rate of the core, we have to update the timekeeper
state to account for the new frequency, as well as for the time it took
to actually modify
On Thu, Aug 8, 2013 at 12:47 PM, Toshi Kani wrote:
> add_memory() and remove_memory() can only handle a memory range aligned
> with section. There are problems when an unaligned range is added and
> then deleted as follows:
>
> - add_memory() with an unaligned range succeeds, but __add_pages()
On Thu, Aug 8, 2013 at 12:17 PM, Oleg Nesterov wrote:
>
>> - somebody setting TASK_SLEEPING -> __schedule() testing the
>> signal_pending_state()
>>
>> and as far as I can tell we have proper barriers for those (the
>> scheduler gets the rq lock
>
> Yes, but... ttwu() takse another lock,
On Thu, 8 Aug 2013, Joe Perches wrote:
> On Thu, 2013-08-08 at 21:32 +0200, Julia Lawall wrote:
> > These patches result from the following semantic patch
> > (http://coccinelle.lip6.fr/), which checks for expression statements
> > separated by , rather than by ;. The rule is quite conservative
On Thu, 2013-08-08 at 21:32 +0200, Julia Lawall wrote:
> These patches result from the following semantic patch
> (http://coccinelle.lip6.fr/), which checks for expression statements
> separated by , rather than by ;. The rule is quite conservative in that it
> only finds cases where this pattern
Em Thu, 08 Aug 2013 23:57:51 +0530
"Naveen N. Rao" escreveu:
> Enable memory error trace event in cper.c
Why do we need to do that? Memory error events are already handled
via edac_ghes module, in a standard way that allows the same
tracing to be used by either BIOS or by direct hardware error
On Thu, 2013-08-08 at 01:54 +0200, Rafael J. Wysocki wrote:
> Hi All,
>
> Two more cleanups for acpi_bind_one() on top of linux-pm.git/linux-next
> follow:
>
> [1/2] Drop unnecessary label from acpi_bind_one().
> [2/2] Print diagnostic messages if device links cannot be created.
Looks good.
From: Julia Lawall
Replace a comma between expression statements by a semicolon.
The rule is quite conservative in that it only finds cases where this
pattern appears after a statement that ends with a semicolon, to ensure
that the expression statements do not form an if branch or loop body
These patches result from the following semantic patch
(http://coccinelle.lip6.fr/), which checks for expression statements
separated by , rather than by ;. The rule is quite conservative in that it
only finds cases where this pattern appears after a statement that ends
with ;, to ensure that the
On Thu, 8 Aug 2013, David Daney wrote:
> I don't know of any bugs currently caused by this unconditional
> local_irq_enable(), but I want to use this function in MIPS/OCTEON
> early boot (when we have early_boot_irqs_disabled). This also makes
> this function have similar semantics to
In order to support multiple SoC models in the mach-bcm
directory, board_bcm.c is being renamed board_bcm281xx.c
Reviewed-by: Markus Mayer
Signed-off-by: Christian Daudt
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 6adb6aec..873817e 100644
---
On Wed, Jul 24, 2013 at 09:32:50PM +0200, Borislav Petkov wrote:
> Btw, this patch is the one that fixes the boot issue on your box,
> correct?
>
> If so, please put a minimal version of it in the next patch set you're
> sending right after
Ok, I've wiggled it ontop of the cpu_has_amd_erratum()
On Thu, Aug 08, 2013 at 11:30:30AM -0600, Stephen Warren wrote:
> On 08/08/2013 02:42 AM, Guenter Roeck wrote:
> > If the regulator subsystem is not configured, you especially don't need
> > or want
> > to pollute the log with an error message.
> DT parsing errors should be reported. However, if
[ attempting to try out claws-mail, hopefully this messages isn't
scrambled ;-) ]
On Thu, 8 Aug 2013 23:57:49 +0530
"Naveen N. Rao" wrote:
> Since we'll be adding multiple trace events to ras.h, we need to protect
> each block appropriately so that they only get included in the right
> places.
On Thu, Aug 8, 2013 at 11:53 AM, Jan Kara wrote:
> On Thu 08-08-13 08:56:28, Andy Lutomirski wrote:
>> On Thu, Aug 8, 2013 at 3:18 AM, Jan Kara wrote:
>> > On Wed 07-08-13 11:00:52, Andy Lutomirski wrote:
>> >> On Wed, Aug 7, 2013 at 10:40 AM, Dave Hansen
>> >> wrote:
>> >> > On 08/07/2013
On 08/08, Linus Torvalds wrote:
>
> As a result, doing a "recalc_sigpending_and_wake(()"
and btw it should die, I think.
> is definitely
> incorrect, because sigpending state cannot actually have changed.
Yes, if we need to wakeup in this case something is already wrong.
> - somebody setting
The current bcm_kona_smc_init function throws a BUG_ON if there's no SMC
device node defined in the device tree.
Since secure API access is optional depending the chip configuration,
fix this by allowing the rest of the code to run even if there's no SMC
device node defined
Reviewed-by: Markus
On Thu, Aug 08, 2013 at 11:57:50PM +0530, Naveen N. Rao wrote:
> +TRACE_EVENT(ghes_platform_memory_event,
> + TP_PROTO(const struct acpi_hest_generic_status *estatus,
> + const struct acpi_hest_generic_data *gdata,
> + const struct cper_sec_mem_err *mem),
> +
> +
Stephen, All,
On 2013-08-08 10:36 +1000, Stephen Rothwell spake thusly:
> On Thu, 8 Aug 2013 10:22:28 +1000 Stephen Rothwell
> wrote:
> >
> > More quick testing with an empty file: v3.9 is OK, v3.10 gives
> > CONFIG_MODULES unset.
Sorry, I don't understand the above. Can you elaborate on what
On Wed, Jul 31, 2013 at 12:39:23PM +0300, Mike Rapoport wrote:
> On Tue, Jul 23, 2013 at 4:28 AM, Rusty Russell wrote:
> > Yes, the subset of x86-64 machines for which there isn't hardware
> > virtualization support is pretty uninteresting.
>
> There are plenty virtual machines in EC2,
On 08/08/13 19:46, Zach Brown wrote:
>>> even though the function is currently unused, I'm hesitating to remove it
>>> as it's part of the reada-API and might be handy for anyone going to use
>>> the API in the future.
>>
>> I agree. As replied here,
>>
Clean up the sdio numbering to be 1-base as defined in HW spec,
instead of the current 0-base
Reviewed-by: Alex Elder
Signed-off-by: Christian Daudt
diff --git a/arch/arm/boot/dts/bcm11351-brt.dts
b/arch/arm/boot/dts/bcm11351-brt.dts
index 67ec524..647a78c 100644
---
Enable sdio for bcm28155 AP board
Reviewed-by: Alex Elder
Signed-off-by: Christian Daudt
diff --git a/arch/arm/boot/dts/bcm28155-ap.dts
b/arch/arm/boot/dts/bcm28155-ap.dts
index 0d66db6..4b0a3ec 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -26,4
On 08/07/2013 08:57 PM, Viresh Kumar wrote:
> On 8 August 2013 00:25, Stephen Warren wrote:
>> 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
On Thu 08-08-13 08:56:28, Andy Lutomirski wrote:
> On Thu, Aug 8, 2013 at 3:18 AM, Jan Kara wrote:
> > On Wed 07-08-13 11:00:52, Andy Lutomirski wrote:
> >> 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
On Thu, 2013-08-08 at 18:35 +0100, Paul McQuade wrote:
> From 9f6231ce16996e35545e20ce1d91abc058f2a6fb Mon Sep 17 00:00:00 2001
> From: Paul McQuade
> Date: Thu, 8 Aug 2013 17:49:22 +0100
> Subject: [PATCH 2/2] Staging: BCM: Removed more whitespace/Errors
>
> Interface Whitespace/Errors Removed
On 08/07/2013 08:42 PM, Viresh Kumar wrote:
> On 8 August 2013 00:20, Stephen Warren wrote:
>> Right, and that's *exactly* what having a cpufreq driver is for; to
>> implement the details of CPU clock management.
>
> cpufreq drivers used to keep such information since a long time,
> probably
On 08/08/2013 11:59 AM, Guenter Roeck wrote:
> On Thu, Aug 08, 2013 at 11:33:13AM -0600, Stephen Warren wrote:
>> On 08/08/2013 05:23 AM, Guenter Roeck wrote:
>>> On 08/08/2013 02:47 AM, Wei Ni wrote:
>> ...
I think get_regulator() will return error values, not only
-EPROBE_DEFER, so we
On Thu, 2013-08-08 at 09:46 -0700, Alexander Duyck wrote:
> On 08/07/2013 10:23 PM, Alex Williamson wrote:
> > On Wed, 2013-08-07 at 11:30 -0700, Alexander Duyck wrote:
> >> On 08/06/2013 07:56 PM, Alex Williamson wrote:
> >>> On Tue, 2013-08-06 at 16:27 -0700, Alexander Duyck wrote:
> On
Hi Huang,
For some reason, I just noticed your question here. But I think it's
important to answer.
On 03/04/2013 12:59 AM, Huang Shijie wrote:
于 2013年03月04日 16:46, Artem Bityutskiy 写道:
Thanks, I forgot we have this great table. BTW, please, do not forget to
update it with information about
Enable memory error trace event in cper.c
Signed-off-by: Naveen N. Rao
---
drivers/acpi/apei/cper.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c
index 33dc6a0..19a9c0b 100644
---
Since we'll be adding multiple trace events to ras.h, we need to protect
each block appropriately so that they only get included in the right
places. Update PCIe AER trace event for this purpose.
Signed-off-by: Naveen N. Rao
---
drivers/pci/pcie/aer/aerdrv_errprint.c | 1 +
Add a trace event for memory error event from generic hardware error
source. We expose all members from the generic error status block, the
generic error data and the cper memory error record.
Signed-off-by: Naveen N. Rao
---
include/trace/events/ras.h | 157
This patch series adds a new trace event for memory errors reported via APEI
generic hardware error source.
- Naveen
Naveen N. Rao (3):
mce: acpi/apei: trace: Include PCIe AER trace event conditionally
mce: acpi/apei: trace: Add trace event for ghes memory error
mce: acpi/apei: trace:
Tomasz,
On Thu, Aug 8, 2013 at 6:54 AM, Tomasz Figa wrote:
...
>> + BUG_ON(lv1ent_section(sent));
>
> Is this condition really a critical one, to the point that the system
> should not continue execution?
>
...
>> if (lv1ent_page(sent)) {
>> - if (*pgcnt != NUM_LV2ENTRIES)
On Thu, Aug 08, 2013 at 12:02:38PM +0200, Borislav Petkov wrote:
> On Wed, Aug 07, 2013 at 07:22:39PM -0700, H. Peter Anvin wrote:
> > How much does this matter?
>
> I know what you're asking :-)
>
> And no, it doesn't really matter as we fail in the patch version check
> so maybe only a comment
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert wrote:
> So what kind of signal was leading to your "stomping on the memory"?
> Was it user generated or something like SIGIO, SIGPIPE or a RT signal?
It was sometimes SIGHUP (for reopening log files) and sometimes
SIGALARM (for various periodic
From: David Daney
As in f21afc25f9ed (smp.h: Use local_irq_{save,restore}() in !SMP
version of on_each_cpu().), we don't want to enable irqs if they are
not already enabled.
I don't know of any bugs currently caused by this unconditional
local_irq_enable(), but I want to use this function in
Fixed by removing trailing whitespace
Signed-off-by: Kumar Gaurav
---
drivers/staging/zram/zram_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 82c7202..f590715 100644
---
On 08/08, Frederic Weisbecker wrote:
>
> I'm all for fixing this. May be we can start by backporting a patch that
> ignores the value of gen_len for instruction breakpoints in x86?
Or perhaps we can start with the something like below.
But probably we should move "attr.bp_len ==
Hi
On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehlé
wrote:
> Hi,
>
> Linux next-20130808 link breaks for me with ARM config multi_v7defconfig.
>
> It seems this is due to the following commit:
>
> 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c
>
> .
On 08/08/2013 10:51 AM, Kumar Gala wrote:
> I'm tossing my hat into the ring of maintainers/reviewers for device tree
> bindings based on history of dealing with DT on embedded PPC and starting
> work on ARM SoCs.
>
> Signed-off-by: Kumar Gala
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Stephen
[ Adding proper people, and the kernel mailing list ]
The patch is definitely incorrect, but the bug is interesting, so I'm
cc'ing more people in case anybody else has any input on this.
The reason I say that the patch is incorrect is because
"legacy_queue()" doesn't actually *do* anything to
> I'm not sure I understand. The old documentation referred to the
> USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers for a phy, and
> your new version only refers to (usb device) PHY_CONTROL. Regardless of
> multiple phys, you're suggesting that we describe less of each phy.
> That seems
301 - 400 of 1616 matches
Mail list logo
