On Tue, 04 Dec 2012 14:28:15 +0900
Jingoo Han wrote:
> From: Marko Katic
>
> Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
> triggers WARN_ON message:
Well, I queued it up.
> ...
>
> --- a/drivers/video/backlight/corgi_lcd.c
> +++ b/drivers/video/backlight/corgi_lcd.c
> @@
On Fri, Nov 30, 2012 at 08:58:31PM +0100, Ingo Molnar wrote:
> I'm pleased to announce the latest, -v18 numa/core release.
>
I collected the results for the following kernels
stats-v8r6TLB flush optimisations, stats from balancenuma tree
numacore-20121130 numacore v17 (tip/master as of
Le Tue, 4 Dec 2012 13:09:22 -0800,
Dmitry Torokhov a écrit :
> On Tue, Nov 27, 2012 at 01:03:56AM -0800, Dmitry Torokhov wrote:
> > The default implementation matches exactly our custom one so we can switch
> > to using the default one. As a bonus the driver will take care of setting
> > GPIO
Dear Oleg,
> Yes, I understand, so DR_RW_EXECUTE should probably work. And I even
> sent the patch (untested/uncompiled). But given that even the simple
> bugfix which started this thread was ignored by maintainers, I am
> not sure how we can convince them this change makes sense ;)
Just to
Jens Axboe writes:
@@ -437,6 +488,14 @@ static int bdi_forker_thread(void *ptr)
spin_lock_bh(>wb_lock);
bdi->wb.task = task;
spin_unlock_bh(>wb_lock);
+
On Mon, Dec 03, 2012 at 05:34:07PM +0100, Stefan Hajnoczi wrote:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet wrote:
> > staging: line6: driver.c
> > The semantic patch that makes this output is available
> > in scripts/coccinelle/api/memdup.cocci.
> >
> > Signed-off-by: Laurent Navet
> >
On Mon, Dec 03, 2012 at 07:57:33PM +0100, Behan Webster wrote:
> However, in order to approximate what gcc is doing in code, obviously
> some math is required. The thought was that macros would hide the
> worst of it, trying not to obfuscate what was actually being done.
Why hide? The thing that
On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
>> Ok, but in comment 11 in the same thread you mention that reverting
>> this patch didn't fix the issue for you:
>>
>> "Reverting that commit on top of 3.7-rc4 did not fix the hang
Directly casting a work_struct pointer to a delayed_work is risky if the
work member of struct delayed_work is ever moved from being the first
member.
Instead, use the inline function to_delayed_work(), which does the same
cast in a safer way (using container_of).
Signed-off-by: Cesar Eduardo
From: "Steven L. Kinney"
-Fix compile error 'is_write' s/b 'bool is_write' for function signature
'amd_iommu_v2_get_set_pc_reg_val'.
-Remove whitespace at end of file; missed by ~/scripts/checkpatch.
Add Kernel configuration selection for AMD IOMMUv2 performance counters.
Add a check that
On Tue, 04 Dec 2012 14:24:28 +0530
"Srivatsa S. Bhat" wrote:
> From: Michael Wang
>
> With stop_machine() gone from the CPU offline path, we can't depend on
> preempt_disable() to prevent CPUs from going offline from under us.
>
> Use the get/put_online_cpus_stable_atomic() APIs to prevent
On Tue, 04 Dec 2012 14:23:41 +0530
"Srivatsa S. Bhat" wrote:
> From: Michael Wang
>
> There are places where preempt_disable() is used to prevent any CPU from
> going offline during the critical section. Let us call them as "atomic
> hotplug readers" (atomic because they run in atomic
The current calculation in pfn_to_bitidx assumes that
(pfn - zone->zone_start_pfn) >> pageblock_order will return the
same bit for all pfn in a pageblock. If zone_start_pfn is not
aligned to pageblock_nr_pages, this may not always be correct.
Consider the following with pageblock order = 10, zone
On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
> Ok, but in comment 11 in the same thread you mention that reverting
> this patch didn't fix the issue for you:
>
> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue."
The bisected commit was from between rc2 and rc3:
$
On Tue, 4 Dec 2012 16:27:47 +0100, Benjamin Tissoires wrote:
> These definitions are not used here, but are defined by the specification.
> Keeping some of them for documentation purposes.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 25
Dear RT Folks,
I'm pleased to announce the 3.0.54-rt78 stable release.
This release is just an update to the new stable 3.0.54 version
and no RT specific changes have been made.
You can get this release via the git tree at:
Dear RT Folks,
I'm pleased to announce the 3.4.21-rt32 stable release.
This release is just an update to the new stable 3.4.21 version
and no RT specific changes have been made.
You can get this release via the git tree at:
On Tue, 4 Dec 2012 16:27:46 +0100, Benjamin Tissoires wrote:
> This avoids the problematic case:
>
> if (condition)
> i2c_hid_dbg(ihid, "Blah blah %d\n", i);
> else
> do_something_very_important();
>
> Which looks correct, however with the previous macro definition,
> this expands
While been restoring fanotify objects I discovered that the minimum
information we provide now is enough to restore notification marks
but still a bit incomplete for fanotify_init system call (the @flags
and @event-flags are unknown). This patch adds missing bits into fdinfo
output.
An example of
On 12/04/2012 10:43 PM, Arnd Bergmann wrote:
On Tuesday 04 December 2012, Eli Billauer wrote:
I'm currently writing some documentation which will cover the API and
also help reading the code, I hope. It takes some time...
Until it's done, let's look at a usage example: Suppose that the
On Tue, 4 Dec 2012 16:27:45 +0100, Benjamin Tissoires wrote:
> We should not initialize to 0 static declarations.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid.c
On Mon, Dec 03, 2012 at 02:42:08PM -0500, Johannes Weiner wrote:
> On Mon, Dec 03, 2012 at 09:30:12AM +0100, Thorsten Leemhuis wrote:
> > >> John was able to reproduce the problem quickly with a kernel that
> > >> contained the patch from your mail. For details see
> > >
> > > [stripped: all the
On Tue, 4 Dec 2012 16:27:44 +0100, Benjamin Tissoires wrote:
> The "comment" part can never be displayed, so we can remove it.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/i2c-hid/Kconfig | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git
On Tue, 4 Dec 2012 16:27:43 +0100, Benjamin Tissoires wrote:
> HID descriptors contains 4 bytes of reserved field.
> The previous implementation was overriding the next fields in struct i2c_hid.
>
> Signed-off-by: Benjamin Tissoires
> ---
> drivers/hid/i2c-hid/i2c-hid.c | 3 ++-
> 1 file
Hi,
On Tue, Dec 04, 2012 at 11:10:42AM -0800, Dmitry Torokhov wrote:
> Hi Li,
>
> On Tue, Dec 04, 2012 at 06:26:29AM -0500, Li Wu wrote:
> > +STM FTK TOUCHSCREEN DRIVER
> > +M: Li Wu
> > +L: device-drivers-de...@blackfin.uclinux.org
> > +W: http://www.st.com
> > +S:
On Mon, Dec 03, 2012 at 12:23:32PM -0700, Stephen Warren wrote:
> On 12/01/2012 07:58 AM, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
> ...
> >> I was thinking of definitions like this:
> >>
> >> static inline u32
On Tue, Dec 04, 2012 at 10:22:12PM +0100, Markus Grabner wrote:
> Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> > On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet
> wrote:
> > > staging: line6: driver.c
> > >
> > > The semantic patch that makes this output is available
> > >
Am Montag, 3. Dezember 2012, 17:34:07 schrieb Stefan Hajnoczi:
> On Mon, Dec 3, 2012 at 2:20 PM, Laurent Navet
wrote:
> > staging: line6: driver.c
> >
> > The semantic patch that makes this output is available
> > in scripts/coccinelle/api/memdup.cocci.
> >
> > Signed-off-by: Laurent Navet
Hi Ulf,
Let me try to better explain:
The idea behind the periodic BKOPS is to check the card's need for BKOPS
periodically in order to prevent an urgent BKOPS need by the card.
In order to actually manage to prevent the urgent BKOPS need, the host
should give the card enough time to perform the
Hi Tejun,
On 12/04/2012 08:47 PM, Tejun Heo wrote:
> Hello, Srivatsa.
>
> On Tue, Dec 04, 2012 at 02:23:41PM +0530, Srivatsa S. Bhat wrote:
>> extern const struct cpumask *const cpu_possible_mask;
>> extern const struct cpumask *const cpu_online_mask;
>> +extern const struct cpumask *const
On 04.12.2012, Daniel Vetter wrote:
> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.
A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or
As its currently implemented, redirection of core dumps to a pipe reader should
be executed such that the reader runs in the namespace of the crashing process,
and it currently does not. This is the only sane way to deal with namespaces
properly it seems to me, and this patch implements that
On Mon, Dec 03, 2012 at 11:28:36PM -0800, Guillermo A. Amaral wrote:
> On Mon, Dec 03, 2012 at 09:24:00PM -0800, Dmitry Torokhov wrote:
> > On Sat, Dec 01, 2012 at 11:36:19PM -0800, Guillermo A. Amaral wrote:
> > > From: "Guillermo A. Amaral"
> > >
> > > Fixed a few minor coding style issues in
On Tue, Nov 27, 2012 at 01:03:56AM -0800, Dmitry Torokhov wrote:
> The default implementation matches exactly our custom one so we can switch
> to using the default one. As a bonus the driver will take care of setting
> GPIO line for us.
>
> Signed-off-by: Dmitry Torokhov
Eric, Sascha, could I
On 04.12.2012, Lekensteyn wrote:
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
> Date: Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable
Ok,
These changes make cper_print_aer more consistent with aer_print_error
which is called in the AER interrupt case. The string in the variable
'prefix' is printed at the beginning of each print statement in
cper_print_aer(). The prefix is a string containing the driver name
and the device's slot
This patch will provide a more reliable and easy way for user-space
applications to have access to AER logs rather than reading them from the
message buffer. It also provides a way to notify user-space when an AER
event occurs.
The aer driver is updated to generate a trace event of function
This header file will define a new trace event that will be triggered when
a AER event occurs. The following data will be provided to the trace
event.
char * dev_name - The name of the slot where the device resides
([domain:]bus:device.function).
u32 status - Either the
On Thu, Nov 29, 2012 at 01:47:28PM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if
> -Original Message-
> From: Michal Nazarewicz [mailto:m...@google.com] On Behalf Of Michal
> Nazarewicz
> Sent: Tuesday, December 04, 2012 2:05 PM
> To: Andrianov, Vitaly; Shilimkar, Santosh
> Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com; a...@arndb.de;
>
On Tue, Dec 4, 2012 at 1:05 PM, Chris Metcalf wrote:
> On 12/4/2012 2:57 PM, Bjorn Helgaas wrote:
>> On Mon, Dec 3, 2012 at 6:28 AM, Wei Yongjun wrote:
>>> From: Wei Yongjun
>>>
>>> Use for_each_pci_dev to simplify the code.
>>>
>>> Signed-off-by: Wei Yongjun
>>> ---
>>>
On Tuesday 04 December 2012, Philip Balister wrote:
> On 12/01/2012 12:48 PM, Arnd Bergmann wrote:
> > On Saturday 01 December 2012, Philip Balister wrote:
> >> On 11/30/2012 09:36 AM, Greg KH wrote:
> >>> Yes, I know of at least one more device other than the ones listed above
> >>> that wants
On Tue, Dec 4, 2012 at 9:41 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
>> Btw: which kernel is known to be the "last good one"?
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
In uf_send_pkt_to_encrypt(), the memory area zeroed by this call to memset() is
overwritten by a call to memcpy() a few instructions later, so it is not needed.
Signed-off-by: Cyril Roelandt
---
drivers/staging/csr/unifi_sme.c |1 -
1 file changed, 1 deletion(-)
diff --git
On Tue, Dec 04, 2012 at 04:59:23AM -0800, Paul E. McKenney wrote:
> Hello, Andy,
>
> The current checkpatch.pl complains about cpp macros defined as follows:
>
> #define callit call my_function
>
> Of course, if you do put parentheses around the definition, your assembler
> will complain.
On Tuesday 04 December 2012, Eli Billauer wrote:
> I'm currently writing some documentation which will cover the API and
> also help reading the code, I hope. It takes some time...
>
> Until it's done, let's look at a usage example: Suppose that the FPGA's
> application is to receive a
On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
> Btw: which kernel is known to be the "last good one"?
As mentioned in the linked bug [1], I bisected it to:
commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
Author: Chris Wilson
Date: Thu Aug 23 13:12:52 2012 +0100
drm/i915: Use cpu
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 250 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds a character device interface to the block GPIO system.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/dev-gpioblock | 34 +
drivers/gpio/gpiolib.c | 208 +++-
include/linux/gpio.h| 10 +
3
The recurring task of providing simultaneous access to GPIO lines (especially
for bit banging protocols) needs an appropriate API.
This patch adds a kernel internal "Block GPIO" API that enables simultaneous
access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
Once
Hi Wolfgang,
On 03/12/12 10:17, Wolfgang Grandegger wrote:
> I re-tried v8 on my AT91-SAM9G45 board and it works fine if
> CONFIG_GPIO_SYSFS is enable. Unfortunately, the access via misc device
> fails if CONFIG_GPIO_SYSFS is not set. That's due to gpio_block_export()
> returning -ENOSYS in
This patch adds block GPIO support to several gpio drivers.
Signed-off-by: Roland Stigge
---
drivers/gpio/gpio-em.c | 23
drivers/gpio/gpio-generic.c | 56 ++
drivers/gpio/gpio-lpc32xx.c | 82
There is a race condition between creating a gpio or gpiochip device and adding
default attributes. This patch fixes this by defining the default attributes as
dev_attrs of the class. For this, it was necessary to create a separate
gpiochip_class besides gpio_class.
Signed-off-by: Roland Stigge
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 84
This set of patches adds:
* Block GPIO API to gpiolib
* Sysfs support for GPIO API, to provide userland access
* Device interface for userland access (alternative to sysfs)
* Devicetree support to instantiate GPIO blocks via DT
* Example implementations in several gpio drivers since they need
On Tue, Dec 04, 2012 at 06:31:10PM -0200, Mauro Carvalho Chehab wrote:
> However, in this particular case, if PCI AER got an error, but the
> device is not found when trying to handle it, it can be an indication
> that the PCI device has a more serious issue. So, I'm in favor
> of changing it, and
On Tue, Dec 04, 2012 at 09:42:55AM -0500, Jeff Moyer wrote:
> Dave Chinner writes:
>
> > On Mon, Dec 03, 2012 at 01:53:39PM -0500, Jeff Moyer wrote:
> >> +static ssize_t cpu_list_store(struct device *dev,
> >> + struct device_attribute *attr, const char *buf, size_t count)
> >> +{
> >>
Em Tue, 4 Dec 2012 20:14:10 +
"Ortiz, Lance E" escreveu:
> > > + if (!dev) {
> > > + pr_info("PCI AER Cannot get PCI device
> > %04x:%02x:%02x.%d\n",
> > > + pcie->device_id.segment, pcie->device_id.bus,
> > > + pcie->device_id.slot,
On 2012-12-04 21:23, Jeff Moyer wrote:
> Jens Axboe writes:
>
>> On 2012-12-03 19:53, Jeff Moyer wrote:
>>> Hi,
>>>
>>> In realtime environments, it may be desirable to keep the per-bdi
>>> flusher threads from running on certain cpus. This patch adds a
>>> cpu_list file to /sys/class/bdi/* to
On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote:
> Relatime should update the inode atime if it is more than a day in the
> future. The original problem seen was a tarball that had a bad atime,
> but could also happen if someone fat-fingers a "touch". The future
> atime will never be
Jens Axboe writes:
> On 2012-12-03 19:53, Jeff Moyer wrote:
>> Hi,
>>
>> In realtime environments, it may be desirable to keep the per-bdi
>> flusher threads from running on certain cpus. This patch adds a
>> cpu_list file to /sys/class/bdi/* to enable this. The default is to tie
>> the
A few lines after this call, we memcpy over the same memory area, so the call to
memset is not necessary.
Signed-off-by: Cyril Roelandt
---
drivers/staging/wlags49_h2/wl_wext.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/wlags49_h2/wl_wext.c
> > + if (!dev) {
> > + pr_info("PCI AER Cannot get PCI device
> %04x:%02x:%02x.%d\n",
> > + pcie->device_id.segment, pcie->device_id.bus,
> > + pcie->device_id.slot, pcie->device_id.function);
>
> Hmm... please correct if I'm wrong, but an error
Zhang Yanfei writes:
> This patch provides a way to VMCLEAR VMCSs related to guests
> on all cpus before executing the VMXOFF when doing kdump. This
> is used to ensure the VMCSs in the vmcore updated and
> non-corrupted.
Apologies for the delay I have been travelling, and I wanted
to at least
On 2012-12-03 19:53, Jeff Moyer wrote:
> Hi,
>
> In realtime environments, it may be desirable to keep the per-bdi
> flusher threads from running on certain cpus. This patch adds a
> cpu_list file to /sys/class/bdi/* to enable this. The default is to tie
> the flusher threads to the same numa
> Hi again Lance.
>
> > diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
> b/drivers/pci/pcie/aer/aerdrv_errprint.c
> []
> > @@ -228,9 +228,14 @@ void cper_print_aer(struct pci_dev *dev, int
> cper_severity,
> > int aer_severity, layer, agent, status_strs_size,
> tlp_header_valid = 0;
> >
On 12/4/2012 2:57 PM, Bjorn Helgaas wrote:
> On Mon, Dec 3, 2012 at 6:28 AM, Wei Yongjun wrote:
>> From: Wei Yongjun
>>
>> Use for_each_pci_dev to simplify the code.
>>
>> Signed-off-by: Wei Yongjun
>> ---
>> arch/tile/kernel/pci.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
On Mon, Dec 3, 2012 at 6:28 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Use for_each_pci_dev to simplify the code.
>
> Signed-off-by: Wei Yongjun
> ---
> arch/tile/kernel/pci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/tile/kernel/pci.c
It is $(obj)/oid_registry.o that is dependent on $(obj)/oid_registry_data.c.
The object file cannot be built until $(obj)/oid_registry_data.c has been
generated.
A periodic and hard to reproduce parallel build failure is due to
this incorrect lib/Makefile dependency. The compile error is
On Tue, Dec 04, 2012 at 05:22:38PM +0100, Jiri Slaby wrote:
> On 12/04/2012 05:11 PM, Johannes Weiner wrote:
> Any chance you could retry with this patch on top?
> >>
> >> It does not apply to -next :/. Should I try anything else?
> >
> > The COMPACTION_BUILD changed to
On 12/01/2012 12:48 PM, Arnd Bergmann wrote:
On Saturday 01 December 2012, Philip Balister wrote:
On 11/30/2012 09:36 AM, Greg KH wrote:
Yes, I know of at least one more device other than the ones listed above
that wants this type of functionality as well, so defining it in a
standard
On Tue, Dec 04, 2012 at 01:56:39AM +0800, yangsheng wrote:
> Relatime should update the inode atime if it is more than a day in the
> future. The original problem seen was a tarball that had a bad atime,
> but could also happen if someone fat-fingers a "touch". The future
> atime will never be
On 01.12.2012 18:59, Peter Hurley wrote:
> (cc'ing Ilya Zykov because the test jig below is based on
> his test program from https://lkml.org/lkml/2012/11/29/368 -- just want
> to give credit where credit is due)
>
> On Fri, 2012-11-30 at 18:52 -0500, Sasha Levin wrote:
>>
>> Still reproducible,
"Bill Huey (hui)" writes:
> I should add that I encountered this on 3.6.0 with some mild
> modifications to the scheduler path that enqueue/dequeue a task before
> any of the schedule exit logic gets hit. The SCHED_FF/FIFO rebalancer
> does much the same so I can't imagine that being the source
Michal Marek wrote:
> The __TIME__ macro is not needed anymore, because the pubkey is included
> in a separate .S file.
Acked-by: David Howells
--
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 12/03/2012 11:22 PM, Minchan Kim wrote:
On Mon, Dec 03, 2012 at 04:57:20PM -0800, John Stultz wrote:
On 12/03/2012 04:00 PM, Minchan Kim wrote:
On Wed, Nov 28, 2012 at 08:18:01PM -0800, John Stultz wrote:
On 11/21/2012 04:36 PM, John Stultz wrote:
2) Being able to use this with tmpfs
On Tue, 2012-12-04 at 18:14 +, David Howells wrote:
> Rusty Russell wrote:
>
> > > +PHONY += _newmodpubkey_
> > > +_newmodpubkey_:
> > > + @rm -f $(MODSECKEY) $(MODPUBKEY)
> > > + $(Q)$(MAKE) -W kernel/modsign_pubkey.o
>
> Please don't do this. It can muck up the dependencies as make
Hi Li,
On Tue, Dec 04, 2012 at 06:26:29AM -0500, Li Wu wrote:
> +STM FTK TOUCHSCREEN DRIVER
> +M: Li Wu
> +L: device-drivers-de...@blackfin.uclinux.org
> +W: http://www.st.com
> +S: Supported
> +F: drivers/input/touchscreen/ftk.c
> +
> +
You have an extra blank line
> On Tuesday 04 December 2012 06:37 PM, Michal Nazarewicz wrote:
>> They are all related to the very same issue, and what the whole patch
>> does is change the type used to store physical addresses from unsigned
>> long to phys_addr_t. This is really a single change.
On Tue, Dec 04 2012, Santosh
A SMSC PHY in power down mode can't be used.
If a SMSC PHY is in this mode in the config_init
stage, the mode "all capable" is set. So the PHY
could then be used.
Signed-off-by: Philippe Reynes
---
Difference between v1 and v2:
- move comment after first block
- update comment to network rules
Em Tue, 04 Dec 2012 10:04:36 -0700
Lance Ortiz escreveu:
> This patch will provide a more reliable and easy way for user-space
> applications to have access to AER logs rather than reading them from the
> message buffer. It also provides a way to notify user-space when an AER
> event occurs.
>
Em Tue, 04 Dec 2012 10:04:30 -0700
Lance Ortiz escreveu:
> This header file will define a new trace event that will be triggered when
> a AER event occurs. The following data will be provided to the trace
> event.
>
> char * dev_name - The name of the slot where the device resides
>
On 12/04/2012 02:34 AM, Heinz Wiesinger wrote:
On Monday 03 December 2012 15:14:12 you wrote:
On 11/05/2012 02:55 PM, Heinz Wiesinger wrote:
On Monday 05 November 2012 11:13:31 Greg KH wrote:
On Mon, Nov 05, 2012 at 01:11:18AM -0800, Jonathan Nieder wrote:
Hi,
In March, Greg KH wrote:
Hi,
> I wanted to use a fm24c04 i2c fram chip with linux. I grepped the source
> and found nothing. I later found that my chip can be handled by at24
> eeprom driver. It creates a sysfs file called eeprom to read from and
> write to the chip. Userspace has no chance to distinguish if it is
>
> Linus Torvalds writes:
>
>> Does that fix the printk's for you too?
>
> Yep, works for me, thanks!
Belated "works for me too" (just in case you were worrying that ia64
was still broken).
-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
From: Serge Hallyn
Date: Mon, 3 Dec 2012 20:17:12 -0600
> When a new nic is created in namespace ns1, the kernel sends a KOBJ_ADD uevent
> to ns1. When the nic is moved to ns2, we only send a KOBJ_MOVE to ns2, and
> nothing to ns1.
>
> This patch changes that behavior so that when moving a nic
On Tue, Dec 04, 2012 at 06:37:41AM -0800, Michel Lespinasse wrote:
> On Mon, Dec 3, 2012 at 6:17 AM, Mel Gorman wrote:
> > On Sat, Dec 01, 2012 at 09:15:38PM +0100, Ingo Molnar wrote:
> >> @@ -732,7 +732,7 @@ static int page_referenced_anon(struct p
> >> struct anon_vma_chain *avc;
> >>
On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, December 03, 2012 10:34 PM
> To: Sethi Varun-B16395
> Cc: Joerg Roedel; linux-kernel@vger.kernel.org; iommu@lists.linux-
> foundation.org; Wood Scott-B07421;
From: Nicolas Ferre
Date: Mon, 3 Dec 2012 13:15:43 +0100
> Macb Ethernet controller requires a RX buffer of 128 bytes. It is
> highly sub-optimal for Gigabit-capable GEM that is able to use
> a bigger DMA buffer. Change this constant and associated macros
> with data stored in the private
On Tue, Dec 04, Jan Beulich wrote:
> This looks necessary but insufficient - there's nothing really
> preventing backend_changed() from being called more than once
> for a given device (is simply the handler of xenbus watch). Hence
> I think either that function needs to be guarded against
(resending due to bounces, sorry for any inconvenience)
On Fri, 2012-11-30 at 09:39 -0600, Steve French wrote:
> But ... the need still remains for more tracing for cifs (I run into
> this a few times a month at least when debugging) - does anyone have
> any ideas for how to add dynamic trace
Michal Marek wrote:
> Using the asm .incbin statement in C sources breaks any gcc wrapper which
> assumes that preprocessed C source is self-contained. Use a separate .S
> file to include the siging key and certificate.
I was trying to avoid that as .S files generally don't crop up in generic
Michal Marek wrote:
> Signed-off-by: Michal Marek
If only perl gave you warnings for this as gcc does...
Acked-by: David Howells
--
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
Rusty Russell wrote:
> > +PHONY += _newmodpubkey_
> > +_newmodpubkey_:
> > + @rm -f $(MODSECKEY) $(MODPUBKEY)
> > + $(Q)$(MAKE) -W kernel/modsign_pubkey.o
Please don't do this. It can muck up the dependencies as make thinks it has
already done this file at this point. Also, rebuilding
On 12/03, u3...@miso.sublimeip.com wrote:
>
> > However. Of course it would be nice to avoid the new option. IMO it
> > would be better to do nothing ;) vsyscall is deprecated, and EMULATE
> > is x86-specific.
>
> The problem is that the current static glibc invokes the vsyscall page,
Yes I know.
On Tue, 2012-12-04 at 18:42 +0200, Gleb Natapov wrote:
> On Tue, Dec 04, 2012 at 08:39:47AM -0700, Alex Williamson wrote:
> > On Tue, 2012-12-04 at 17:30 +0200, Gleb Natapov wrote:
> > > On Tue, Dec 04, 2012 at 08:21:55AM -0700, Alex Williamson wrote:
> > > > On Tue, 2012-12-04 at 13:48 +0200,
On 12/04/2012 01:26 AM, Marcelo Tosatti wrote:
On Wed, Nov 28, 2012 at 10:40:56AM +0530, Raghavendra K T wrote:
On 11/28/2012 06:42 AM, Marcelo Tosatti wrote:
Don't understand the reasoning behind why 3 is a good choice.
Here is where I came from. (explaining from scratch for
completeness,
On Tue, 2012-12-04 at 10:04 -0700, Lance Ortiz wrote:
> These changes make cper_print_aer more consistent with aer_print_error
> which is called in the AER interrupt case. The string in the variable
> 'prefix' is printed at the beginning of each print statement in
> cper_print_aer(). The prefix is
On Tue, Dec 4, 2012 at 12:11 AM, Peter Ujfalusi wrote:
> Hi Bryan,
>
> On 12/03/2012 07:32 PM, Bryan Wu wrote:
>> On Mon, Dec 3, 2012 at 6:13 AM, Peter Ujfalusi wrote:
>> Actually, I'm waiting for some feedback from DT maintainers about this
>> new binding. But it looks find to me.
>
> Would it
On Mon, 3 Dec 2012, Mel Gorman wrote:
> On Fri, Nov 30, 2012 at 12:37:49PM -0800, Linus Torvalds wrote:
> > So if this is a migration-specific scalability issue, then it might be
> > possible to solve by making the mutex be a rwsem instead, and have
> > migration only take it for reading.
> >
> >
101 - 200 of 948 matches
Mail list logo
