On 25 March 2015 at 09:48, Linus Torvalds wrote:
> drm/i915: Don't try to reference the fb in get_initial_plane_config()
>
> On Mon, Mar 23, 2015 at 7:11 PM, Dave Airlie wrote:
>>
>> a few people reported an oops that looks to be fixed in drm-next already,
>> so I've pulled the patch back.
>
The mm-of-the-moment snapshot 2015-03-24-17-02 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On 25 March 2015 at 08:50, Daniel Stone wrote:
> Hi,
>
> On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
>> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
>> +struct drm_framebuffer *fb,
>> +struct
On Tue, 2015-03-24 at 11:34 +0800, Yijing Wang wrote:
> Now we could use pci_scan_host_bridge() to scan
> pci buses, provide powerpc specific pci_host_bridge_ops.
>
> Signed-off-by: Yijing Wang
> CC: Benjamin Herrenschmidt
> CC: linuxppc-...@lists.ozlabs.org
> ---
>
On Tue, Mar 24, 2015 at 4:42 PM, Dave Hansen wrote:
> On 03/24/2015 03:28 PM, Andy Lutomirski wrote:
>> Your function appears to be getting it for write (I assume that's what
>> the unlazy_fpu is for), so I'd rather have it called
>> tsk_get_xsave_field_for_write or something like that.
>
> It
drm/i915: Don't try to reference the fb in get_initial_plane_config()
On Mon, Mar 23, 2015 at 7:11 PM, Dave Airlie wrote:
>
> a few people reported an oops that looks to be fixed in drm-next already,
> so I've pulled the patch back.
Hmm. At least from Josh's report, he also needs
On Mon, 23 Mar 2015, Kirill A. Shutemov wrote:
> On Sun, Mar 22, 2015 at 05:28:47PM -0700, Hugh Dickins wrote:
> > On Thu, 19 Mar 2015, Kirill A. Shutemov wrote:
> >
> > > Currently we take naive approach to page flags on compound -- we set the
> > > flag on the page without consideration if the
On 03/24/2015 06:08 PM, David Rientjes wrote:
> Mempools based on slab caches with object constructors are risky because
> element allocation can happen either from the slab cache itself, meaning
> the constructor is properly called before returning, or from the mempool
> reserve pool, meaning the
On 03/24/2015 03:28 PM, Andy Lutomirski wrote:
> Your function appears to be getting it for write (I assume that's what
> the unlazy_fpu is for), so I'd rather have it called
> tsk_get_xsave_field_for_write or something like that.
It should be entirely read-only.
For MPX (the only user of
On Tue, Mar 24, 2015 at 04:42:35PM +0100, Michael S. Tsirkin wrote:
> pci_msi_init_pci_dev and pci_msi_off share a lot of code.
> This used to be justified since pci_msi_init_pci_dev
> wasn't compiled in when CONFIG_PCI_MSI is off.
> Now that it is, let's reuse code.
>
> Signed-off-by: Michael S.
On Tue, Mar 24, 2015 at 04:29:32PM +0530, Sudip Mukherjee wrote:
> the lcd type as defined in the Kconfig is not matching in the code.
> as a result the rs, rw and en pins were getting interchanged.
> Kconfig defines the value of PANEL_LCD to be 1 if we select custom
> configuration but in the
Dear Kukjin,
On 03/24/2015 05:09 PM, Kukjin Kim wrote:
> Chanwoo Choi wrote:
>>
>> Dear Kukjin,
>>
> Hi,
>
>> Could you please pick or review this patch-set?
>>
> Sorry for late response and honestly I was looking at the review in ml ;-)
>
> Anyway I have no objection on this series except
On Tue, Mar 24, 2015 at 02:56:33PM +0530, Sudip Mukherjee wrote:
> with reference to the previous patch of the series, fixed the
> lcd type in module parameters.
Sudip, it's better to avoid fragmenting patches like you did, because
it will result in a kernel state where there is an inconsistency
On Tue, 2015-03-24 at 23:05 +, Srinivas Kandagatla wrote:
> On 24/03/15 22:36, Mark Brown wrote:
> >> +int regmap_get_max_register(struct regmap *map)
> >> +{
> >> + return map->max_register ? : -EINVAL;
> >> +}
> >
> > Please write the logic out properly, don't abuse the ternery operator.
>
mempool_alloc() does not support __GFP_ZERO since elements may come from
memory that has already been released by mempool_free().
Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly
initialize it to 0.
Cc: Lars Ellenberg
Cc: Jens Axboe
Signed-off-by: David Rientjes
---
Mempools created for slab caches should use
mempool_create_slab_pool().
Cc: Lars Ellenberg
Cc: Jens Axboe
Signed-off-by: David Rientjes
---
drivers/block/drbd/drbd_main.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/block/drbd/drbd_main.c
blk_init_rl() allocates a mempool using mempool_create_node() with node
local memory. This only allocates the mempool and element list locally
to the requeue queue node.
What we really want to do is allocate the request itself local to the
queue. To do this, we need our own alloc and free
On Tue, 24 Mar 2015 18:10:05 -0500
> Although the ring buffer design is coded to avoid disabling
> interrupts, in this case there does not appear to be a practical way
> to solve this problem without disabling interrupts for a short time.
> To accommodate those architectures where disabling
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Tuesday, March 24, 2015 3:57 PM
> To: Michael Opdenacker
> Cc: Hannes Reinecke; jbottom...@parallels.com; Elliott, Robert (Server
> Storage); linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re:
CONFIG_SLAB_DEBUG doesn't exist, CONFIG_DEBUG_SLAB does.
Signed-off-by: David Rientjes
---
include/linux/slab.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/slab.h b/include/linux/slab.h
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -18,7 +18,7 @@
In case of no memory allocation, the return should be
ENOMEM instead of ENOSPC. Well, for the other case, in which
the buffer head is not allocated, in that case -EIO should
be returned.
Signed-off-by: Sanidhya Kashyap
---
fs/bfs/dir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Elements backed by the slab allocator are poisoned when added to a
mempool's reserved pool.
It is also possible to poison elements backed by the page allocator
because the mempool layer knows the allocation order.
This patch extends mempool element poisoning to include memory backed by
the page
When tracing the behavior of multiple fio jobs running in parallel
our performance team observed that some scsi_dispatch_cmd_done events
appeared to occur earlier, often several microseconds earlier, than
their associated scsi_dispatch_cmd_start event in the trace records.
Other interrupt events
Mempools keep elements in a reserved pool for contexts in which
allocation may not be possible. When an element is allocated from the
reserved pool, its memory contents is the same as when it was added to
the reserved pool.
Because of this, elements lack any free poisoning to detect
All occurrences of mempools based on slab caches with object constructors
have been removed from the tree, so disallow creating them.
We can only dereference mem->ctor in mm/mempool.c without including
mm/slab.h in include/linux/mempool.h. So simply note the restriction,
just like the comment
Mempools based on slab caches with object constructors are risky because
element allocation can happen either from the slab cache itself, meaning
the constructor is properly called before returning, or from the mempool
reserve pool, meaning the constructor is not called before returning,
depending
On 24/03/15 22:37, Mark Brown wrote:
On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote:
+ /* regmap_get_reg_stride(): Report the register address stride
+ *
+ * Report the register address stride, mainly intended to for use by
+ * generic infrastructure built on top of
On 24/03/15 22:36, Mark Brown wrote:
On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.
In what way would it be used?
Its
The innermost copyloops were optimized for POWER7's 128-byte cacheline.
This patch adds optimization for the e6500, which has a 64-byte
cacheline.
We basically do this by stripping loop bodies using L1_CACHE_BYTES
ifdeferry, replace 128 with L1_CACHE_BYTES, and 7's with L1_CACHE_SHIFTs.
We also
POWER7 has a dedicated stream prefetcher that is pre-programmed via
dcbt rX,rY,0b010?0 instructions in the beginning of vmx_copy.
e6500 has no such prefetcher, so we revert to using regular dcbt
instructions in-loop:
1. at __copy_tofrom_user_power7 entry, we prefetch the first
src and dest lines
This enables the VMX/ALTIVEC optimised copy-to/from-user code in
arch/powerpc/lib/copyuser_power7.S. The e6500 does, and the e5500
does not, have ALTIVEC.
Signed-off-by: Kim Phillips
---
arch/powerpc/include/asm/cputable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, 3 Mar 2015 15:12:02 +0530 Keerthy wrote:
> Add external 32k clock feature. The internal clock will be gated during
> suspend.
> Hence make use of the external 32k clock so that rtc is functional accross
> suspend/resume.
>
> ...
>
> @@ -446,6 +449,7 @@ static const struct
On Mon, 23 Mar 2015, Kirill A. Shutemov wrote:
> On Sun, Mar 22, 2015 at 05:02:58PM -0700, Hugh Dickins wrote:
> > On Thu, 19 Mar 2015, Kirill A. Shutemov wrote:
> > > On Thu, Mar 19, 2015 at 11:29:52AM -0700, Dave Hansen wrote:
> > > > On 03/19/2015 10:08 AM, Kirill A. Shutemov wrote:
> > > > >
On Mon, 16 Mar 2015 20:56:39 +0300 Yury Norov wrote:
> Function 'bitmap_empty' has it's own implementation.
> But it's clearly as simple as:
> "find_first_bit(src, nbits) == nbits"
> The same is true for 'bitmap_full'.
>
> Underscored versions of 'bitmap_[empty,full]' are not
> needed
On Tue, Mar 24, 2015 at 10:30:08PM +, Srinivas Kandagatla wrote:
> +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t offset, size_t count)
> +{
Hi,
On 24 March 2015 at 16:07, Gerd Hoffmann wrote:
> +static int virtio_gpu_crtc_page_flip(struct drm_crtc *crtc,
> +struct drm_framebuffer *fb,
> +struct drm_pending_vblank_event *event,
> +
On 25/12/14 09:48, Kevin Cernekee wrote:
> V5->V6: Incorporate several fixes/enhancements from Jaedon Shin:
>
> - Fix register read/modify/write in RAC flush code.
>
> - Fix use of "SYS_HAS_CPU_BMIPS32_3300" Kconfig symbol.
>
> - Add base platform support for 7358 and 7362.
>
> The DTS
On Tue, 24 Mar 2015 16:08:34 -0600 Toshi Kani wrote:
> This patchset enhances MTRR checks for the kernel huge I/O mapping,
> which was enabled by the patchset below:
> https://lkml.org/lkml/2015/3/3/589
>
> The following functional changes are made in patch 7/7.
> - Allow pud_set_huge() and
On Tuesday, March 24, 2015 10:02:33 PM Hanjun Guo wrote:
> Some fixes since last version:
>
> - Add a patch 19/23 for disabling ACPI for Xen on ARM64 for now to fix
>compile errors on XEN ACPI, Stefano and Julien are ok with this
>temporary solution.
> - Add patch "ARM64 / ACPI: Don't
read_cache_page returns -EIO on error, so the return should be checked
against ERROR_VALUE instead of NULL.
Signed-off-by: Chengyu Song
---
fs/logfs/segment.c | 4 ++--
fs/logfs/super.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/logfs/segment.c
On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote:
> + /* regmap_get_reg_stride(): Report the register address stride
> + *
> + * Report the register address stride, mainly intended to for use by
> + * generic infrastructure built on top of regmap.
> + */
> +int
On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:
> This patch introduces regmap_get_max_register() function which would be
> used by the infrastructures like eeprom framework built on top of
> regmap.
In what way would it be used?
> +int regmap_get_max_register(struct regmap
This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like eeprom framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.
Signed-off-by: Srinivas Kandagatla
---
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.
Signed-off-by: Maxime Ripard
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla
---
This patch adds just providers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were
Document the return values of KVA mapping functions,
pud_set_huge(), pmd_set_huge, pud_clear_huge() and
pmd_clear_huge().
Simplify the conditions to select HAVE_ARCH_HUGE_VMAP
in the Kconfig, since X86_PAE depends on X86_32.
There is no functional change in this patch.
Signed-off-by: Toshi Kani
v1->v2:
As suggested by Michal, we can split up the v1 patch into 2 patches.
The first patch addresses potentially incorrect usages of ACCESS_ONCE().
The second patch is more of a "cleanup" patch to convert the rest of
the ACCESS_ONCE() reads in mm/ to use the new READ_ONCE() API.
This makes
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.
On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring
From: Maxime Ripard
Now that we have the EEPROM framework, we can consolidate the common driver
code. Move the driver to the framework, and hopefully, it will fix the sysfs
file creation race.
Signed-off-by: Maxime Ripard
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
This patch adds MAINTAINERS to eeprom framework.
Signed-off-by: Srinivas Kandagatla
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d66a97d..ee7ba92 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3657,6 +3657,15 @@ T: git
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple eeprom framework.
Signed-off-by: Srinivas Kandagatla
---
.../devicetree/bindings/eeprom/qfprom.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
We converted some of the usages of ACCESS_ONCE to READ_ONCE in
the mm/ tree since it doesn't work reliably on non-scalar types.
This patch removes the rest of the usages of ACCESS_ONCE, and use
the new READ_ONCE API for the read accesses. This makes things
cleaner, instead of using
This patch adds just consumers part of the framework just to enable easy
review.
Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were
MTRRs contain fixed and variable entries. mtrr_type_lookup()
may repeatedly call __mtrr_type_lookup() to handle a request
that overlaps with variable entries. However,
__mtrr_type_lookup() also handles the fixed entries, which
do not have to be repeated. Therefore, this patch creates
separate
'mtrr_state.enabled' contains the FE (fixed MTRRs enabled)
and E (MTRRs enabled) flags in MSR_MTRRdefType. Intel SDM,
section 11.11.2.1, defines these flags as follows:
- All MTRRs are disabled when the E flag is clear.
The FE flag has no affect when the E flag is clear.
- The default type
__mtrr_type_lookup() checks MTRR fixed ranges when
mtrr_state.have_fixed is set and start is less than
0x10. However, the 'else if (start < 0x100)'
in the code checks with a wrong address as it has
an extra-zero in the address. The code still runs
correctly as this check is meaningless,
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.
Signed-off-by: Srinivas Kandagatla
---
drivers/base/regmap/regmap.c | 12
include/linux/regmap.h | 7 +++
2 files changed, 19
Commit 38c5ce936a08 ("mm/gup: Replace ACCESS_ONCE with READ_ONCE")
converted ACCESS_ONCE usage in gup_pmd_range() to READ_ONCE, since
ACCESS_ONCE doesn't work reliably on non-scalar types.
This patch also fixes the other ACCESS_ONCE usages in gup_pte_range()
and __get_user_pages_fast() in
On Tue, Mar 24, 2015 at 3:20 PM, Dave Hansen wrote:
> From: Dave Hansen
>
> The MPX code appears to be saving off the FPU in an unsafe
> way. It does not disable preemption or ensure that the
> FPU state has been allocated.
>
> This patch introduces a new helper which will do both of
> those
Thankyou all for providing inputs and comments on previous versions of this
patchset.
Here is the v3 of the patchset addressing all the issues raised as
part of previous versions review.
This patchset adds a new simple EEPROM framework to kernel.
Up until now, EEPROM drivers were stored in
mtrr_type_lookup() returns 0xFF when it cannot return a valid
MTRR memory type since MTRRs are disabled. This patch defines
MTRR_TYPE_INVALID to clarify the meaning of this value, and
documents its usage.
There is no functional change in this patch.
Signed-off-by: Toshi Kani
---
From: Pawel Moll
Until now, perf framework never defined the meaning of the timestamps
captured as PERF_SAMPLE_TIME sample type. The values were obtaining
from local (sched) clock, which is unavailable in userspace. This made
it impossible to correlate perf data with any other events. Other
When an MTRR entry is inclusive to a requested range, i.e.
the start and end of the request are not within the MTRR
entry range but the range contains the MTRR entry entirely,
__mtrr_type_lookup() ignores such a case because both
start_state and end_state are set to zero.
This bug can cause the
On Tue 2015-03-24 12:30:34, Eduardo Valentin wrote:
> On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote:
> >
> > When periodic mode is not enabled, it is neccessary to force reads.
> >
> > Signed-off-by: Pavel Machek
>
> This is a malformed patch. here is patch output (or git am)
>
This patch adds an additional argument, 'uniform', to
mtrr_type_lookup(), which returns 1 when a given range is
covered uniformly by MTRRs, i.e. the range is fully covered
by a single MTRR entry or the default type.
pud_set_huge() and pmd_set_huge() are changed to check the
new 'uniform' flag to
This patchset enhances MTRR checks for the kernel huge I/O mapping,
which was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589
The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page
mapping to a range covered
This patch adds a --jit option to perf inject.
This options injects MMAP records into the perf.data
file to cover the jitted code mmaps. It also emits
ELF images for each function in the jidump file.
Those images are created where the jitdump file is.
The MMAP records point to that location as
On Tue, Mar 24, 2015 at 06:12:56PM -0400, Chengyu Song wrote:
> fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
> the last extent that will fit in user array. If 1 is returned, the return
> value may eventually returned to user space, which should not happen,
>
This patch series extends perf record/report/annotate to enable
profiling of jitted (just-in-time compiled) code. The current
perf tool provides very limited support for profiling jitted
code for some runtime environments. But the support is experimental
and cannot be used in complex environments.
This is a standalone JVMTI library to help profile Java jitted
code with perf record/perf report. The library is not installed
or compiled automatically by perf Makefile. It is not used
directly by perf. It is arch agnostic and has been tested on
X86 and ARM. It needs to be used with a Java
Add Java function descriptor demangling support.
Something bfd cannot do.
Use the JAVA_DEMANGLE_NORET flag to avoid decoding the
return type of functions.
Signed-off-by: Stephane Eranian
---
tools/perf/util/Build | 1 +
tools/perf/util/demangle-java.c | 199
Em Tue, Mar 24, 2015 at 04:00:36PM -0600, David Ahern escreveu:
> On 3/24/15 3:57 PM, Arnaldo Carvalho de Melo wrote:
> >With the patch below, that leaves printing something, using whatever UI, to
> >the
> >tool, acceptable?
>
> I keep forgetting about the python bindings.
Oh, its not just
On 03/23, Badhri Jagan Sridharan wrote:
> >Some initial questions:
> >
> > 1. Have you seen the pending tracepoint patches to add
> > tracepoints to the framework[1]?
> >
> > 2. Have you considered using tracepoints and the ability to
> > register callbacks on tracepoints and/or
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 62a5d44..ec533e7 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++
On Tue, Mar 24, 2015 at 10:23:56PM +0100, Thomas Niederprüm wrote:
> This patch adds the module parameter "contrast" to determine the
> contrast value that is used to initialize the display. This
> setting applies to all instances of the driver.
>
> Signed-off-by: Thomas Niederprüm
Do we still
fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
the last extent that will fit in user array. If 1 is returned, the return
value may eventually returned to user space, which should not happen, according
to manpage of ioctl.
Signed-off-by: Chengyu Song
---
On 21/03/15 16:45, Stefan Agner wrote:
> The const declaration for char* is actually duplicated, however
> the array of strings is currently not constant. However, typically
> the dt_compat array is declared as const char *const. Follow
> that convention and also add the __initconst macro for
On Tue, Mar 24, 2015 at 10:23:51PM +0100, Thomas Niederprüm wrote:
> The 130X controllers are very similar from the configuration point of view.
> The configuration registers for the SSD1305/6/7 are bit identical (except the
> the VHCOM register and the the default values for clock setup
On Tue, Mar 24, 2015 at 10:58:46PM +0100, Greg KH wrote:
> On Tue, Mar 24, 2015 at 12:08:32PM -0500, Felipe Balbi wrote:
> > Hi Greg,
> >
> > Because of ELC, I have to cut short on patch queueing this time. In any
> > case,
> > we have some pretty good content for v4.1.
> >
> > Patches have
On Fri, Mar 20, 2015 at 04:19:36PM +0100, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Fri, Mar 20, 2015 at 1:54 PM, Greg Kroah-Hartman
> wrote:
> > On Tue, Mar 10, 2015 at 10:34:43PM +0100, Geert Uytterhoeven wrote:
> >> Gcc < 4.3 doesn't understand binary constants (0b*):
> >>
> >>
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Tuesday, March 24, 2015 10:27 AM
> To: Matias Bjørling; Jens Axboe; linux-kernel@vger.kernel.org; linux-
> fsde...@vger.kernel.org
> Cc: Ming Lin-SSI
> Subject: Re: [PATCH 1/6] block: add support for carrying a stream
On 3/24/2015 5:14 PM, Peter Zijlstra wrote:
On Tue, Mar 24, 2015 at 03:21:32PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf
Tile includes a hypervisor hook to deliver messages to arbitrary
tiles, so we can use that to raise an interrupt as soon as
possible on our own core.
On Tue, Mar 24, 2015 at 12:02:15PM -0500, Felipe Balbi wrote:
> Hi Greg,
>
> Here's a single fix for isp1760. Please consider merging it
> to usb/linus.
>
> cheers
>
> The following changes since commit bc465aa9d045feb0e13b4a8f32cc33c1943f62d6:
>
> Linux 4.0-rc5 (2015-03-22 16:50:21 -0700)
>
On Thu, 19 Mar 2015 23:04:39 +0900 Roman Pen wrote:
> If suitable block can't be found, new block is allocated and put into a head
> of a free list, so on next iteration this new block will be found first.
>
> ...
>
> Cc: sta...@vger.kernel.org
>
> ...
>
> --- a/mm/vmalloc.c
> +++
On 3/24/15 3:57 PM, Arnaldo Carvalho de Melo wrote:
With the patch below, that leaves printing something, using whatever UI, to the
tool, acceptable?
I keep forgetting about the python bindings.
Your patch serves the purpose. Thanks, Arnaldo.
--
To unsubscribe from this list: send the line
On Tue, Mar 24, 2015 at 12:08:32PM -0500, Felipe Balbi wrote:
> Hi Greg,
>
> Because of ELC, I have to cut short on patch queueing this time. In any case,
> we have some pretty good content for v4.1.
>
> Patches have been tested with platforms I have around (heh, took me a while
> to do that
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Tuesday, March 24, 2015 10:08 AM
> To: Jeff Moyer; Jens Axboe
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; Ming Lin-
> SSI
> Subject: Re: [PATCH RFC] Support for write stream IDs
>
> On
Em Tue, Mar 24, 2015 at 06:29:56PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Mar 24, 2015 at 12:10:17PM -0400, David Ahern escreveu:
> > Use of a bad filter currently generates the message:
> > Error: failed to set filter with 22 (Invalid argument)
> >
> > Add the event name to make it
Ingo, Peter, Thomas,
These patches from Daniel extend the arch-generic sched_clock
implementation so that it can be safely called from NMI (or FIQ on ARM)
context. They also optimize the sched_clock logic to improve cache
performance. I wanted to send them along so they could be queued in
-tip
On Tue, Mar 24, 2015 at 10:23:54PM +0100, Thomas Niederprüm wrote:
> This patch adds the module parameter "refreshrate" to set delay for the
> deferred io. The refresh rate is given in units of Hertz. The default
> refresh rate is 1 Hz. The refresh rate set through the newly introduced
> parameter
The android_fence_release() function checks for active sync points
by calling list_empty() on the list head embedded on the sync
point. However, it is only valid to use list_empty() on nodes that
have been initialized with INIT_LIST_HEAD() or list_del_init().
Because the list entry has likely
On 3/24/2015 5:15 PM, Frederic Weisbecker wrote:
On Tue, Mar 24, 2015 at 03:21:33PM -0400, cmetc...@ezchip.com wrote:
From: Chris Metcalf
Add the TIF_NOHZ flag appropriately.
Add call to user_exit() on entry to do_work_pending() and on entry
to syscalls via do_syscall_trace_enter(), and also
On 03/24/2015 03:46 PM, Ming Lin-SSI wrote:
-Original Message-
From: Jens Axboe [mailto:ax...@kernel.dk]
Sent: Tuesday, March 24, 2015 10:08 AM
To: Jeff Moyer; Jens Axboe
Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; Ming Lin-
SSI
Subject: Re: [PATCH RFC] Support for
On Tue, Mar 24, 2015 at 01:55:04PM -0700, Alistair Strachan wrote:
> The android_fence_release() function checks for active sync points
> by calling list_empty() on the list head embedded on the sync
> point. However, it is only valid to use list_empty() on nodes that
> have been initialized with
On Fri, 20 Mar 2015 20:51:47 +0300 Alexey Dobriyan wrote:
> /proc/$PID/cmdline truncates output at PAGE_SIZE. It is easy to see with
>
> $ cat /proc/self/cmdline $(seq 1037) 2>/dev/null
>
> However, command line size was never limited to PAGE_SIZE but to 128 KB and
> relatively recently
On Thu, Mar 19, 2015 at 4:29 PM, Alessandro Zummo wrote:
> On Wed, 18 Mar 2015 10:37:26 -0700
> John Stultz wrote:
>
>> On Wed, Jan 28, 2015 at 10:27 AM, Alessandro Zummo
>> wrote:
>> > On Thu, 29 Jan 2015 00:12:09 +0800
>> > Xunlei Pang wrote:
>> >
>> >> ping Alessandro
>> >
>> > -EBUSY .
On Tue, Mar 24, 2015 at 1:17 PM, Denys Vlasenko wrote:
> On 03/24/2015 05:55 PM, Brian Gerst wrote:
Might be nice to place a more generic description there, which
registers are expected to be saved by user-space calling in here, etc.
>>>
>>> __kernel_vsyscall entry point has the same
Em Tue, Mar 24, 2015 at 12:10:17PM -0400, David Ahern escreveu:
> Use of a bad filter currently generates the message:
> Error: failed to set filter with 22 (Invalid argument)
>
> Add the event name to make it clear to which event the filter
> failed to apply:
> Error: Failed to set filter on
On 3/24/15 3:15 PM, Arnaldo Carvalho de Melo wrote:
/me scratches head, should be missing something embarassingly simple :-/
ptr = sample->raw_data + field->offset;
raw_data is *guaranteed* to be misaligned. From kernel/events/core.c:
struct {
Upon successful rename(), update ctime and mtime of
old/new_dir, as posix specifies.
Signed-off-by: Taesoo Kim
---
fs/hpfs/namei.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fs/hpfs/namei.c b/fs/hpfs/namei.c
index bdbc2c3..8d8669c 100644
--- a/fs/hpfs/namei.c
+++
101 - 200 of 2394 matches
Mail list logo
