On Fri, 2013-07-12 at 18:10 -0700, Joe Perches wrote:
> On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> > The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> > special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> > and add a pci_device_id.driver_data
On Fri, 2013-07-12 at 18:17 -0700, Greg KH wrote:
> On Fri, Jul 12, 2013 at 05:58:07PM -0700, Darren Hart wrote:
> > The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> > special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> > and add a pci_device_id.driver_data
On 07/12/2013 10:31 PM, Yinghai Lu wrote:
> On Fri, Jul 12, 2013 at 9:39 PM, H. Peter Anvin wrote:
>> On 07/12/2013 09:19 PM, Yinghai Lu wrote:
PG_reserved,
+ PG_uninitialized2mib, /* Is this the right spot? ntz - Yes - rmh
*/
PG_private,
Hi,
Now I've had a look at the whole discussion.
Basically, DW I2C core provides a good enough (and quite direct) way
to control tHIGH and tLOW timing specs, *HCNT and *LCNT registers.
But from my experience (with a slightly old version of DW I2C core
around 2005, version 1.06a or so), DW I2C
On Fri, Jul 12, 2013 at 9:39 PM, H. Peter Anvin wrote:
> On 07/12/2013 09:19 PM, Yinghai Lu wrote:
>>> PG_reserved,
>>> + PG_uninitialized2mib, /* Is this the right spot? ntz - Yes - rmh
>>> */
>>> PG_private, /* If pagecache, has fs-private data */
>
> The
On Fri, 2013-07-12 at 09:46 +0200, Alexander Gordeev wrote:
> On Thu, Jul 11, 2013 at 04:00:37PM -0700, Nicholas A. Bellinger wrote:
> > On Thu, 2013-07-11 at 12:26 +0200, Alexander Gordeev wrote:
> > > On Wed, May 22, 2013 at 07:03:05PM +0200, Jens Axboe wrote:
> > > > On Wed, May 22 2013,
On Sat, Jul 13, 2013 at 01:17:36PM +0900, Satoru Takeuchi wrote:
> At Thu, 11 Jul 2013 15:20:29 -0700,
> Greg Kroah-Hartman wrote:
> >
> > This is the start of the stable review cycle for the 3.0.86 release.
> > There are 8 patches in this series, all will be posted as a response
> > to this one.
On 07/12/2013 09:19 PM, Yinghai Lu wrote:
>> PG_reserved,
>> + PG_uninitialized2mib, /* Is this the right spot? ntz - Yes - rmh */
>> PG_private, /* If pagecache, has fs-private data */
The comment here is WTF...
-hpa
--
To unsubscribe from this
This is the remaining set of SCSI patches for the merge window. it's
mostly driver updates (scsi_debug, qla2xxx, storvsc, mp3sas). There are
also several bug fixes in fcoe, libfc, and megaraid_sas. We also have a
couple of core changes to try to make device destruction more
deterministic.
The
On Thu, Jul 11, 2013 at 7:03 PM, Robin Holt wrote:
> During boot of large memory machines, a significant portion of boot
> is spent initializing the struct page array. The vast majority of
> those pages are not referenced during boot.
>
> Change this over to only initializing the pages when they
At Thu, 11 Jul 2013 15:20:29 -0700,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.0.86 release.
> There are 8 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
At Thu, 11 Jul 2013 15:19:30 -0700,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.9.10 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
At Thu, 11 Jul 2013 15:11:00 -0700,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.53 release.
> There are 11 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
At Thu, 11 Jul 2013 15:01:17 -0700,
Greg Kroah-Hartman wrote:
>
>
> I'm sitting on top of over 170 more patches that have been marked for
> the stable releases right now that are not included in this set of
> releases. The fact that there are this many patches for stable stuff
> that
On Thu, Jul 11, 2013 at 06:42:03PM -0700, Hugh Dickins wrote:
> On Thu, 11 Jul 2013, Michal Hocko wrote:
> > On Thu 11-07-13 12:26:34, Dave Chinner wrote:
> > > > We are wating for page under writeback but neither of the 2 paths starts
> > > > in xfs code. So I do not think waiting for
Commit-ID: c0b3450f101523a49823fa93d155f1d258e5ac6f
Gitweb: http://git.kernel.org/tip/c0b3450f101523a49823fa93d155f1d258e5ac6f
Author: Kees Cook
AuthorDate: Fri, 12 Jul 2013 15:50:17 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 12 Jul 2013 16:14:08 -0700
x86: Make sure IDT is page
Commit-ID: 3a783f6e39cc6c89da8846312f29ca47affaa470
Gitweb: http://git.kernel.org/tip/3a783f6e39cc6c89da8846312f29ca47affaa470
Author: H. Peter Anvin
AuthorDate: Fri, 12 Jul 2013 16:48:12 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 12 Jul 2013 16:48:12 -0700
x86, suspend: Handle
There is currently some inconsistency about the "frame pointer" on ARM.
r11 is the register with assemblers recognize and disassemblers often
print as "fp", and which is sufficient for stack unwinding when using
the APCS frame pointer option; but when unwinding with the Exception
Handling ABI, the
We need a perf_arch_fetch_caller_regs for at least some software events
to be able to get a callchain; even user stacks won't work without
at least the CPSR bits for non-user-mode (see perf_callchain). In
particular, profiling context switches needs this.
This records the state of the point at
On Fri, Jul 12, 2013 at 12:45 AM, Robin Holt wrote:
> At the very least, I think we could change to:
> static void __init __free_pages_memory(unsigned long start, unsigned long end)
> {
> int order;
>
> while (start < end) {
> order = ffs(start);
>
>
On Thu, Jul 11, 2013 at 7:03 PM, Robin Holt wrote:
> Currently, memmap_init_zone() has all the smarts for initializing a
> single page. When we convert to initializing pages in a 2MiB chunk,
> we will need to do this equivalent work from two separate places
> so we are breaking out a helper
On 7/11/13 11:50 PM, "Camelia Groza" wrote:
>This removes the open coded fnic_trace_ctrl_open() function
>and replaces file operations references to the function
>with simple_open() instead.
>
>Found using coccinelle.
>
>Signed-off-by: Camelia Groza
>---
> drivers/scsi/fnic/fnic_debugfs.c |
On Thu, Jul 11, 2013 at 10:39:30PM -0400, Dave Jones wrote:
> Just saw this during boot after an unclean shutdown. It hung afterwards.
>
> [ 97.162665] XFS: Assertion failed: xfs_dir2_sf_lookup(args) == ENOENT,
> file: fs/xfs/xfs_dir2_sf.c, line: 358
> [ 97.173730] []
On Fri, 12 Jul 2013, Dave Jones wrote:
>
> Here's a fun trick:
>
> trinity -c perf_event_open -C4 -q -l off
>
> Within about a minute, that brings any of my boxes to its knees.
> The softlockup detector starts going nuts, and then the box wedges solid.
are you running with the patch
[PATCH
This patch makes the necessary changes at the x86 architecture specific
layer to enable the presence of the CONFIG_QUEUE_RWLOCK kernel option
to replace the plain read/write lock by the queue read/write lock.
Signed-off-by: Waiman Long
---
arch/x86/Kconfig |3 +++
This patch set introduces a queue-based read/write implementation that
is both faster and fairer than the current read/write lock. It can
also be used as a replacement for ticket spinlocks that are highly
contended if lock size increase is not an issue.
There is no change in the interface. By
This patch introduces a read/write lock implementation that put waiting
readers and writers into a queue instead of actively contending the
lock like the regular read/write lock. This will improve performance in
highly contended situation by reducing the cache line bouncing effect.
In addition,
On Fri, Jul 12, 2013 at 03:05:05PM -0700, Guenter Roeck wrote:
> On Thu, Jul 11, 2013 at 03:19:30PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.9.10 release.
> > There are 15 patches in this series, all will be posted as a response
> > to this one.
On Sat, Jul 13, 2013 at 02:24:07AM +0200, Rafael J. Wysocki wrote:
> On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> > On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> > >
> > > > In any
On Sat, Jul 13, 2013 at 05:15:16AM +0400, Sergei Shtylyov wrote:
> Hello.
>
>Can't get to sleep, sigh...
>
> On 07/13/2013 04:57 AM, Greg KH wrote:
>
> >>Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car
> >>SoCs.
> >>Though being two separate devices, they have to
On Fri, Jul 12, 2013 at 05:58:07PM -0700, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> and add a pci_device_id.driver_data structure and functions to handle
> platform setup.
>
>
Hello.
Can't get to sleep, sigh...
On 07/13/2013 04:57 AM, Greg KH wrote:
Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car SoCs.
Though being two separate devices, they have to be driven together because of
the shared start/stop register (located in Gyro-ADC
Hello,
On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel"
On Fri, 2013-07-12 at 17:58 -0700, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
> special handling. Use the MinnowBoard PCI Subsystem ID to detect this
> and add a pci_device_id.driver_data structure and functions to handle
> platform setup.
trivial
Use the DMI interface to detect the board for UART_CLOCK selection
per Greg K-H.
Resend PCH_GBE_PHY_REGS_LEN define cleanup.
Rewrite of PCH_GBE MinnowBoard support to be completely independent from any
platform or board files. It requests the GPIO line in the pch_gbe driver and
minimizes the
Avoid using magic numbers when we have perfectly good defines just lying
around.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 +-
1 file
Use the DMI interface rather than manually matching DMI strings.
Signed-off-by: Darren Hart
Cc: Michael Brunner
Cc: Greg Kroah-Hartman
---
drivers/tty/serial/pch_uart.c | 71 +--
1 file changed, 49 insertions(+), 22 deletions(-)
diff --git
The MinnowBoard uses an AR803x PHY with the PCH GBE which requires
special handling. Use the MinnowBoard PCI Subsystem ID to detect this
and add a pci_device_id.driver_data structure and functions to handle
platform setup.
The AR803x does not implement the RGMII 2ns TX clock delay in the trace
On Sat, Jul 13, 2013 at 03:51:42AM +0400, Sergei Shtylyov wrote:
> Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car
> SoCs.
> Though being two separate devices, they have to be driven together because of
> the shared start/stop register (located in Gyro-ADC still). At
Adding the essential David Gibson to the Cc list.
On Fri, 12 Jul 2013, Davidlohr Bueso wrote:
> The hugetlb_instantiation_mutex serializes hugepage allocation and
> instantiation
> in the page directory entry. It was found that this mutex can become quite
> contended
> during the early phases
From: "Steven Rostedt (Red Hat)"
Currently, RCU tracepoints save only a pointer to strings in the
ring buffer. When displayed via the /sys/kernel/debug/tracing/trace file
they are referenced like the printf "%s" that looks at the address
in the ring buffer and prints out the string it points
From: "Steven Rostedt (Red Hat)"
There are several tracepoints (mostly in RCU), that reference a string
pointer and uses the print format of "%s" to display the string that
exists in the kernel, instead of copying the actual string to the
ring buffer (saves time and ring buffer space).
But this
This has been on my todo list for a while. I've been promising Paul
to get a way to have his tracepoints work for user tools, and I finally
got around to it :-)
As his tracepoints just save a pointer to a string in the ring buffer
and have the output use that pointer with a "%s" printf field,
From: "Steven Rostedt (Red Hat)"
All the RCU tracepoints and functions that reference char pointers do
so with just 'char *' even though they do not modify the contents of
the string itself. This will cause warnings if a const char * is used
in one of these functions.
The RCU tracepoints store
From: "Steven Rostedt (Red Hat)"
The RCU_STATE_INITIALIZER() macro is used only in the rcutree.c file
as well as the rcutree_plugin.h file. It is passed as a rvalue to
a variable of a similar name. A per_cpu variable is also created
with a similar name as well.
The uses of
On Fri, 12 Jul 2013, Luis R. Rodriguez wrote:
> Kicked out the first Linux kernel backports release under the new
> project name, "backports" that hopefully clarifies this a generic
> backport project now. Backported subsystems in this release:
> [0]
>
From: Rafael J. Wysocki
According to Matthew Garrett, "Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
On Fri, Jul 12, 2013 at 11:10 PM, Daniel Drake wrote:
> On Thu, Jul 11, 2013 at 5:54 PM, Haojian Zhuang
> wrote:
>>> Well, Daniel Drake spoke up for OLPC. Does that count?
>>
>> We don't know they used DT on Marvell MMP2/MMP3. So they don't have DTS file
>> in kernel, we could use both old name
On Fri, Jul 12, 2013 at 05:48:13PM -0400, Santosh Shilimkar wrote:
> Most of the kernel code assumes that max*pfn is maximum pfns because
> the physical start of memory is expected to be PFN0. Since this
> assumption is not true on ARM architectures, the meaning of max*pfn
> is number of memory
On Thursday, July 11, 2013 08:34:30 PM Greg Kroah-Hartman wrote:
> On Thu, Jul 11, 2013 at 10:57:46PM -0400, John W. Linville wrote:
> > On Thu, Jul 11, 2013 at 08:50:23PM -0400, Theodore Ts'o wrote:
> >
> > > In any case, I've been very conservative in _not_ pushing bug fixes to
> > > Linus
On Sat, Jul 13, 2013 at 03:42:55AM +0400, Sergei Shtylyov wrote:
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 86d5220..e8275fa 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1668,7 +1668,7 @@ u64
Add the driver for Gyro-ADC/speed-pulse interfaces found in Renesas R-Car SoCs.
Though being two separate devices, they have to be driven together because of
the shared start/stop register (located in Gyro-ADC still). At this time, only
speed-pulse interface is fully supported, the Gyro-ADC is
On 07/12/2013 04:36 PM, Christian Sünkenberg wrote:
>
> Jonas tried your patch and it fixes suspend/resume on his T43, although
> IMHO the safest approach would be to just add an exception for
> Vendor==Intel && Family==6 && Model==13, or more generally Vendor==Intel
> && !supports_long_mode, as
On Friday, July 12, 2013 04:28:36 PM Toshi Kani wrote:
> On Fri, 2013-07-12 at 23:40 +0200, Rafael J. Wysocki wrote:
> > On Friday, July 12, 2013 03:12:24 PM Toshi Kani wrote:
> > > On Fri, 2013-07-12 at 23:13 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, July 12, 2013 03:01:15 PM Toshi Kani
On 07/13/2013 03:08 AM, Sergei Shtylyov wrote:
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across
Kicked out the first Linux kernel backports release under the new
project name, "backports" that hopefully clarifies this a generic
backport project now. Backported subsystems in this release:
* Ethernet
* Wireless
* Bluetooth
* NFC
* GPU
* Media
* Regulator
Go read the git tree
Hello,
On 07/11/2013 01:57 AM, H. Peter Anvin wrote:
> On 07/10/2013 01:52 PM, Christian Sünkenberg wrote:
>> Hello,
>>
>> On 05/01/2013 07:33 PM, H. Peter Anvin wrote:
>>> On 05/01/2013 10:01 AM, Jonas Heinrich wrote:
Hello, I tried the newest kernel, 3.9 today but the bug is still
Hi!
> > > This permits to reassign keyboard LEDs to something else than keyboard
> > > "leds"
> > > state, by adding keyboard led and modifier triggers connected to a series
> > > of VT input LEDs, themselves connected to VT input triggers, which
> > > per-input device LEDs use by default.
The hugetlb_instantiation_mutex serializes hugepage allocation and instantiation
in the page directory entry. It was found that this mutex can become quite
contended
during the early phases of large databases which make use of huge pages - for
instance
startup and initial runs. One clear example
From: Hayes Wang
Date: Fri, 12 Jul 2013 16:26:16 +0800
>>> drivers/net/usb/r815x.c:38:16: sparse: cast to restricted __le32
>>> drivers/net/usb/r815x.c:67:15: sparse: cast to restricted __le32
>>> drivers/net/usb/r815x.c:69:13: sparse: incorrect type in assignment
>>> (different base types)
>
From: Hayes Wang
Date: Fri, 12 Jul 2013 16:26:15 +0800
> config: make ARCH=avr32 allyesconfig
> drivers/net/usb/r8152.c: In function 'rtl8152_start_xmit':
> drivers/net/usb/r8152.c:956: warning: integer overflow in expression
>
>955memset(tx_desc, 0, sizeof(*tx_desc));
> > 956
Hello.
On 07/13/2013 02:25 AM, Russell King - ARM Linux wrote:
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning
On 5/23/2013 2:23 PM, David Milburn wrote:
> Dynamically allocate buf to prevent warnings:
>
> drivers/block/mtip32xx/mtip32xx.c: In function ‘mtip_hw_read_device_status’:
> drivers/block/mtip32xx/mtip32xx.c:2823: warning: the frame size of 1056 bytes
> is larger than 1024 bytes
>
On Fri, 12 Jul 2013, naveen yadav wrote:
> Hi All
>
> I am working on tmpfs. During code analysis I found shmem driver
> register itself as tmpfs .
>
> cat /proc/meminfo Shmem field read NR_SHMEM enum filed and shows used
> memory in tmpfs
>
>
> [root@localhost linux-3.8.2]# cat /proc/meminfo
Since the IDT is referenced from a fixmap, make sure it is page aligned.
Merge with 32-bit one, since it was already aligned to deal with F00F bug.
This avoids the risk of it ever being moved in the bss and having the
mapping be offset, resulting in calling incorrect handlers.
Signed-off-by: Kees
That was the busted patch. See the v2 I sent. Only 64-bit needs
alignment. And after looking more at it, the idt in head_64.S could be
entirely dropped in favor of using the one in arch/x86/kernel/traps.c
(after moving it out of the #ifdef.
-Kees
On Fri, Jul 12, 2013 at 3:28 PM, H. Peter Anvin
On Fri, 2013-07-12 at 23:40 +0200, Rafael J. Wysocki wrote:
> On Friday, July 12, 2013 03:12:24 PM Toshi Kani wrote:
> > On Fri, 2013-07-12 at 23:13 +0200, Rafael J. Wysocki wrote:
> > > On Friday, July 12, 2013 03:01:15 PM Toshi Kani wrote:
> > > > On Fri, 2013-07-12 at 22:42 +0200, Rafael J.
On 07/12/2013 11:30 AM, Kees Cook wrote:
>
> - .word 0 # 32-bit align idt_desc.address
> + .word PAGE_SIZE # page align idt_desc.address
>
... and this is totally confused. This didn't change alignment one
iota, it only put the value 4096 into
3.10 fails to boot from mmc root without this patch.
An early version of this patch was to be included in in 3.10
but apparently didn't make it.
--- ./drivers/mmc/core/core.c.orig2013-06-30 16:13:29.0 -0600
+++ ./drivers/mmc/core/core.c2013-07-12 15:17:15.377466795 -0600
@@
On 07/12/2013 11:30 AM, Kees Cook wrote:
> Since the IDT is referenced from a fixmap, make sure it is page aligned.
> This avoids the risk of it ever being moved in the bss and having the
> fixmap fail.
>
> Signed-off-by: Kees Cook
> Reported-by: PaX Team
> Cc: sta...@vger.kernel.org
> ---
>
On Sat, Jul 13, 2013 at 01:55:58AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:
>
>> DMA bounce limit is the maximum direct DMA'able memory beyond which
>> bounce buffers has to be used to perform dma operations. SCSI driver
>> relies on dma_mask but
On 07/12/2013 01:33 PM, Greg Kroah-Hartman wrote:
>
> Is it _really_ all that hard to remember what to mark for stable
> inclusion? If you figure it out after you have committed the patch,
> then just put a copy of it somewhere to remind yourself. That seems to
> be what both David and I do
On 07/12/2013 12:53 PM, Steven Rostedt wrote:
> On Fri, 2013-07-12 at 12:44 -0700, Linus Torvalds wrote:
>
>> They can be useful for "local" notes (they can be very powerful for
>> certain workflows), but they won't be pulled and pushed by me.
>
> Perhaps notes can be used as that reminder to
On 07/12/2013 12:31 PM, Joe Perches wrote:
> Documentation shouldn't be executable.
>
> Signed-off-by: Joe Perches
Acked-by: Rob Herring
> ---
> diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> old mode 100755
> new mode
On Thu, Jul 11, 2013 at 03:19:30PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.9.10 release.
> There are 15 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
Hello.
On 07/13/2013 01:48 AM, Santosh Shilimkar wrote:
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across
The blk_queue_bounce_limit() API parameter 'dma_mask' is actually the
maximum address the device can handle rather than a dma_mask. Rename
it accordingly to avoid it being interpreted as dma_mask.
No functional change.
The idea is to fix the bad assumptions about dma_mask wherever it could
be
Most of the kernel code assumes that max*pfn is maximum pfns because
the physical start of memory is expected to be PFN0. Since this
assumption is not true on ARM architectures, the meaning of max*pfn
is number of memory pages. This is done to keep drivers happy which
are making use of of these
In the effort of using memblock instead of bootmem allocator, ARM arch
needs to be converted to use NO_BOOTMEM. With NO_BOOTMEM change,
now we use memblock allocator to reserve space for crash kernel to
have one less dependency with nobootmem allocator wrapper.
Hopefully the NO_BOOTMEM memblock
Most of the kernel assumes that PFN0 is the start of the physical
memory (RAM). This assumptions is not true on most of the ARM SOCs
and hence and if one try to update the ARM port to follow the assumptions,
we end of breaking the dma bounce limit for few block layer drivers.
One such example is
The series is an attempt to move ARM port to NO_BOOTMEM. As discussed
on list NO_BOOTMEM move needed updates to max*pfn meaning to be maximum
PFNs but that breaks the dma_mask for few block layer drivers since
ARM start of physical memory is not PFN0 unlike most of the architectures.
Some more
DMA bounce limit is the maximum direct DMA'able memory beyond which
bounce buffers has to be used to perform dma operations. SCSI driver
relies on dma_mask but its calculation is based on max_*pfn which
don't have uniform meaning across architectures. So make use of
dma_max_pfn() which is expected
Tested and ready to go.
Thanks,
Srinivas
-Original Message-
From: Jonathan Cameron [mailto:ji...@kernel.org]
Sent: Friday, July 12, 2013 11:45 AM
To: Alexander Holler
Cc: Srinivas Pandruvada; linux-kernel@vger.kernel.org;
linux-...@vger.kernel.org; Jonathan Cameron; Pandruvada,
Hello.
On 07/11/2013 11:25 AM, Geert Uytterhoeven wrote:
When builtin (CONFIG_USB_FOTG210_UDC=y):
LD drivers/usb/gadget/built-in.o
WARNING: drivers/usb/gadget/built-in.o(.data+0xbf8): Section mismatch in
reference from the variable fotg210_driver to the function
Tested. You can add my ack.
Acked-by:Srinivas Pandruvada
On 07/10/2013 01:32 AM, Alexander Holler wrote:
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which
Tested. You can add my ack.
Acked-by:Srinivas Pandruvada
On 07/10/2013 01:31 AM, Alexander Holler wrote:
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which
Tested. You can add my ack.
Acked-by:Srinivas Pandruvada
On 07/10/2013 01:31 AM, Alexander Holler wrote:
Add a MODULE_DEVICE_TABLE in order to let hotplug mechanisms automatically
load the driver.
This makes it also possible to use the usual driver name instead of
HID-SENSOR-2000xx which
On Friday, July 12, 2013 03:12:24 PM Toshi Kani wrote:
> On Fri, 2013-07-12 at 23:13 +0200, Rafael J. Wysocki wrote:
> > On Friday, July 12, 2013 03:01:15 PM Toshi Kani wrote:
> > > On Fri, 2013-07-12 at 22:42 +0200, Rafael J. Wysocki wrote:
> > > > On Friday, July 12, 2013 08:51:29 AM Toshi Kani
On Fri, Jul 12, 2013 at 04:28:20PM -0400, Steven Rostedt wrote:
>
> I would suspect that machines that allow unprivileged users would be
> running distro kernels, and not the latest release from Linus, and thus
> even a bug that "can allow an unprivileged user to crash the kernel" may
> still be
On Fri, Jul 12, 2013 at 01:21:07PM -0700, Linus Torvalds wrote:
> So you could have something like
>
> #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY | O_RDWR)
> #define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT | O_ACCMODE)
>
> and then use
>
>if ((flags & O_TMPFILE_MASK) !=
(3212): []
> __do_softirq+0x447/0x4d0
> [ 116.555857] softirqs last disabled at (3223): []
> irq_exit+0x86/0x120
> [ 116.556760] CPU: 0 PID: 12510 Comm: modprobe Tainted: GW
> 3.10.0-next-20130712-sasha #3956
> [ 116.557812] task: 8807c8173000 ti: 8807c72a600
On Fri, Jul 12, 2013 at 09:07:19PM +, KY Srinivasan wrote:
[...]
> > Well now it might look like a bug that you don't test the result
> > of wait_for_completion_timeout(). Maybe update the comment to
> > explain why it's OK to continue anyway?
>
> I put in the comment in the patch explaining
On Fri, 2013-07-12 at 23:13 +0200, Rafael J. Wysocki wrote:
> On Friday, July 12, 2013 03:01:15 PM Toshi Kani wrote:
> > On Fri, 2013-07-12 at 22:42 +0200, Rafael J. Wysocki wrote:
> > > On Friday, July 12, 2013 08:51:29 AM Toshi Kani wrote:
> > > > On Fri, 2013-07-12 at 09:24 +0900, Yasuaki
> -Original Message-
> From: Ben Hutchings [mailto:b...@decadent.org.uk]
> Sent: Friday, July 12, 2013 4:17 PM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com;
On Fri, Jul 12, 2013 at 04:47:44PM -0400, Theodore Ts'o wrote:
> On Fri, Jul 12, 2013 at 09:50:51PM +0200, Willy Tarreau wrote:
> > So probably we should incite patch contributors to add a specific
> > tag such as "Fixes: 3.5 and later", so that non-important patches
> > do not need the Cc:stable
On Friday, July 12, 2013 03:01:15 PM Toshi Kani wrote:
> On Fri, 2013-07-12 at 22:42 +0200, Rafael J. Wysocki wrote:
> > On Friday, July 12, 2013 08:51:29 AM Toshi Kani wrote:
> > > On Fri, 2013-07-12 at 09:24 +0900, Yasuaki Ishimatsu wrote:
> > > > (2013/07/11 1:47), Toshi Kani wrote:
> > > > >
On Fri, 2013-07-12 at 22:42 +0200, Rafael J. Wysocki wrote:
> On Friday, July 12, 2013 08:51:29 AM Toshi Kani wrote:
> > On Fri, 2013-07-12 at 09:24 +0900, Yasuaki Ishimatsu wrote:
> > > (2013/07/11 1:47), Toshi Kani wrote:
> > > > device->driver_data needs to be cleared when releasing its data,
>
On Friday, July 12, 2013 04:05:08 PM Mika Westerberg wrote:
> On Fri, Jul 12, 2013 at 02:01:30AM +0200, Rafael J. Wysocki wrote:
> > Index: linux-pm/drivers/pci/hotplug/acpiphp.h
> > ===
> > ---
Friday, May 17, 2013, 11:52:17 AM, you wrote:
> On Fri May 17 2013 11:04:50 Sander Eikelenboom wrote:
>>
>> Friday, May 17, 2013, 10:25:24 AM, you wrote:
>>
>> > On Thu May 16 2013 19:41:42 Sander Eikelenboom wrote:
>> >> Hi Hans / Mauro,
>> >>
>> >> With 3.10.0-rc1 (including the cx25821
On Friday, July 12, 2013 04:18:50 PM Mika Westerberg wrote:
> On Fri, Jul 12, 2013 at 01:34:20AM +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > I've made some progress with my ACPIPHP rework since I posted the series
> > last
> > time and here goes an update.
> >
> > First off, the previous
1 - 100 of 938 matches
Mail list logo
