On Fri, 5 Sep 2014, Paolo Bonzini wrote:
> Il 05/09/2014 20:33, Thomas Gleixner ha scritto:
> >> > update_vsyscall(tk);
> >> > -update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET);
> >> >
> >> > tk_update_ktime_data(tk);
> >> > +update_pvclock_gtod(tk, action &
On Fri, Sep 5, 2014 at 2:30 PM, Murali Karicheri wrote:
> On 09/05/2014 03:23 PM, Bjorn Helgaas wrote:
>>
>> On Fri, Aug 08, 2014 at 03:45:32PM -0400, Murali Karicheri wrote:
>>>
>>> Keystone PCI controller has a limitation that memory read request
>>> size must not exceed 256 bytes. This is a
On Tue, Sep 02, 2014 at 10:44:53AM -0500, Seth Forshee wrote:
> Here's an updated set of patches for allowing fuse mounts from pid and
> user namespaces. I discussed some of the issues we debated with the last
> patch set (and a few others) with Eric at LinuxCon, and the updates here
> mainly
As announced in [1] gcc will increase its major number yearly but we don't
need to include gcc version specific quirks for every version normally.
This patch allows to compile every kernel with all new versions of gcc
without adding a specific compiler-gccX.h header. We do so by clamping
the
Il 05/09/2014 20:33, Thomas Gleixner ha scritto:
>> >update_vsyscall(tk);
>> > - update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET);
>> >
>> >tk_update_ktime_data(tk);
>> > + update_pvclock_gtod(tk, action & TK_CLOCK_WAS_SET);
> Why are you moving the update between vsycall and pvclock
On 09/05/2014 03:00 PM, Arnd Bergmann wrote:
On Friday 05 September 2014 14:33:54 Murali Karicheri wrote:
This looks like it's a shared register of some sort that doesn't
really belong into the registers of a particular port. Could it
be that it's actually for the PHY?
This a shared device
On 09/05/2014 01:14 PM, Peter Hurley wrote:
>
> Here's how I read the two statements.
>
> First, the commit message:
>
> "It [this commit] documents that CPUs [supported by the Linux kernel]
> _must provide_ atomic one-byte and two-byte naturally aligned loads and
> stores."
>
> Second, in
On 09/05/2014 03:23 PM, Bjorn Helgaas wrote:
On Fri, Aug 08, 2014 at 03:45:32PM -0400, Murali Karicheri wrote:
Keystone PCI controller has a limitation that memory read request
size must not exceed 256 bytes. This is a hardware limitation and
add a quirk to force this limit on all downstream
Paul E. McKenney wrote:
>On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>>> This commit documents the fact that it is not safe to use bitfields as
>>> shared variables in synchronization algorithms. It also documents that
>>> CPUs
On Thu, 04 Sep, at 10:37:53PM, Matt Fleming wrote:
>
> Thanks Ard, I'll take a look in the morning.
Maarten, could you try out this patch?
---
>From a058d81d9687671813560af72f34d63da3cc16bc Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 5 Sep 2014 14:52:26 +0100
Subject: [PATCH]
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
> On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
> > On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> >> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
> >>
> >> CPUs without single-byte and
This fixes a hang when initializing SMP CPUs at this point in the boot:
x86: Booting SMP configuration
node #0, CPUs: #1_
Fixes: 4ba2968420fa ("percpu: Resolve ambiguities in
__get_cpu_var/cpumask_var_t")
Signed-off-by: Ted Percival
---
arch/x86/kernel/apic/x2apic_cluster.c | 1 +
On 09/05/2014 01:12 PM, Peter Zijlstra wrote:
>>
>> ... and I'm wondering if I should _remove_ pre-EV56 configurations or
>> move the default choice and produce a warning about unsupported Alpha
>> CPUs instead?
>>
>
> depends BROKEN
>
> or is that deprecated?
>
Just rip it out, like I did
On 09/05/2014 03:38 PM, Marc Gauthier wrote:
> Paul E. McKenney wrote:
>> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
This commit documents the fact that it is not safe to use bitfields as
shared variables in
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
> > So does this patch depends on a patch that removes pre EV56 alpha
> > support? I'm all for removing that, but I need to see the patch merged
> > before we can do this.
>
> I'm working on that but Alpha's Kconfig is not quite
From: "John L. Hammond"
In mdc_setup() and mdc_precleanup() call mdc_llog_init() and
mdc_llog_finish() directly rather than through the OBD method wrappers
obd_llog_init() and obd_llod_finish(). Simplify the prototypes of
mdc_llog_init() and mdc_llog_finish() according to their uses.
On 09/05/2014 01:34 PM, Ted Percival wrote:
> This fixes a hang when initializing SMP CPUs at this point in the boot:
Looks like git-send-email picked up the wrong From address. I'll
resubmit with a consistent email address.
--
To unsubscribe from this list: send the line "unsubscribe
On Fri, Sep 05, 2014 at 03:24:35PM -0400, Peter Hurley wrote:
> On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> > On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
> >> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
>
> [cut]
>
> >>>
From: "John L. Hammond"
Remove the unused function llog_ioctl() and the file
lustre/obdclass/llog_ioctl.c.
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/include/lustre_log.h |4 -
drivers/staging/lustre/lustre/obdclass/Makefile|2 +-
From: "John L. Hammond"
Remove the unused function sptlrpc_conf_target_get_rules() and its
supporting functions.
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/include/lustre_sec.h |3 -
drivers/staging/lustre/lustre/ptlrpc/sec_config.c | 327
2
From: "John L. Hammond"
Remove the unused files lustre/obdclass/local_storage.[ch].
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/obdclass/Makefile|2 +-
.../staging/lustre/lustre/obdclass/local_storage.c | 894
From: "John L. Hammond"
In osc_request.c there is no reason to handle any llog contexts since
they are never setup. Remove the functions unused function
osc_llog_init() and the obsolete function osc_llog_finish(). Remove
the llog cleanup code in osc_disconnect() and osc_precleanup().
From: "John L. Hammond"
Remove the unused OBD device methods mdc_pin() and mdc_unpin().
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/mdc/mdc_request.c | 90 ---
1 file changed, 90 deletions(-)
diff --git
From: "John L. Hammond"
The function mgc_cancel() is never invoked as an OBD device method and
is only called directly from mgc_process_log() so remove it.
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/mgc/mgc_request.c | 17 ++---
1 file changed, 2
From: "John L. Hammond"
In mgc_process_cfg_log() remove code to handle
LLOG_CONFIG_ORIG_CTXT. This context is not setup on clients.
Signed-off-by: John L. Hammond
---
drivers/staging/lustre/lustre/mgc/mgc_request.c | 84 ++-
1 file changed, 4 insertions(+), 80
From: "John L. Hammond"
Remove the unused OBD device methods:
obd_brw()
obd_cancel()
obd_cancel_unused()
obd_change_cbdata()
obd_create_async()
obd_enqueue()
obd_enqueue_rqset()
obd_extent_calc()
obd_llog_connect()
obd_llog_finish()
obd_llog_init()
From: "John L. Hammond"
Remove the unused OBD device methods:
lov_brw()
lov_cancel()
lov_cancel_unused()
lov_change_cbdata()
lov_enqueue()
lov_extent_calc()
lov_getattr()
lov_merge_lvb()
lov_punch()
lov_setattr()
lov_sync()
and their supporting
From: "John L. Hammond"
Move the structures defined in lustre/include/obd_ost.h to the one
file that uses them (lustre/osc/osc_request.c). Remove the unused
function osc_update_enqueue(). Remove the then empty header
lustre/include/obd_ost.h.
Signed-off-by: John L. Hammond
---
From: "John L. Hammond"
Remove the unused OBD device methods:
osc_brw()
osc_cancel()
osc_cancel_unused()
osc_change_cbdata()
osc_enqueue()
osc_punch()
osc_sync()
and their supporting functions.
Signed-off-by: John L. Hammond
---
From: "John L. Hammond"
Howdy,
This series yet removes more dead and obsolete code from drivers/staging/lustre
in the form of methods from struct obd_ops and server specific llog handling.
John L. Hammond (12):
staging/lustre/lov: remove unused OBD methods
staging/lustre/osc: remove unused
On 09/04/2014 03:25 AM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
> ---
> arch/x86/Kconfig | 12 +++
> arch/x86/kernel/Makefile | 1 +
> arch/x86/kernel/coreboot.c | 232
> +
> 3 files changed, 245 insertions(+)
> create mode
On 08/26/2014 06:32 PM, Andy Lutomirski wrote:
> On Mon, Jul 28, 2014 at 8:38 PM, Andy Lutomirski wrote:
>> This applies to:
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git seccomp-fastpath
>>
>> Gitweb:
>>
On 09/05/2014 03:52 PM, Peter Zijlstra wrote:
> On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
>> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>>
>> CPUs without single-byte and double-byte loads and stores place some
>> "interesting" requirements on
On Fri, 5 Sep 2014 16:28:06 +0900 Joonsoo Kim wrote:
> mm-slab_common-move-kmem_cache-definition-to-internal-header.patch
> in mmotm makes following build failure.
>
> ../mm/kmemcheck.c:70:7: error: dereferencing pointer to incomplete type
> ../mm/kmemcheck.c:83:15: error: dereferencing
On Fri, Sep 05, 2014 at 09:04:44PM +0200, Karol Lewandowski wrote:
> Applicable for 3.14-stable only.
>
> This commit drops duplicate declaration of struct usb_functionfs_descs_head
> erronousely added in commit 28c5980b54 ("usb: gadget: f_fs: resurect
> usb_functionfs_descs_head structure").
>
On 09/05/2014 12:21 PM, Thomas Gleixner wrote:
> On Fri, 5 Sep 2014, Florian Fainelli wrote:
>> On 09/05/2014 02:05 AM, Mark Rutland wrote:
>>> +- brcm,irq-can-wake: if present, this means the L2 controller can be
>>> used as a
>>> + wakeup source for system suspend/resume.
>
On Fri, Sep 05, 2014 at 10:31:49AM -0700, Linus Torvalds wrote:
> So quite frankly, the whole perf_pmu_migrate_context() thing looks
> completely and fundamentally broken.
Yes, agreed. We can go play very nasty games, but fundamentally agreed.
> Or even just say: "if somebody takes down a CPU
When viewing the /proc/interrupts, there is no information about which
GPIO bank a specific gpio interrupt is hooked on to. This is more than a
bit irritating as such information can esily be provided back to the
user and at times, can be crucial for debug.
So, instead of displaying something
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>
> CPUs without single-byte and double-byte loads and stores place some
> "interesting" requirements on concurrent code. For example (adapted
> from Peter
This fixes a hang when initializing SMP CPUs at this point in the boot:
x86: Booting SMP configuration
node #0, CPUs: #1_
Fixes: 4ba2968420fa ("percpu: Resolve ambiguities in
__get_cpu_var/cpumask_var_t")
Signed-off-by: Ted Percival
---
arch/x86/kernel/apic/x2apic_cluster.c | 1 +
Linus,
here are I2C driver bugfixes for the 3.17 release. Details can be found
in the commit messages, yet I think this is typical driver stuff. Please
pull.
Thanks,
Wolfram
The following changes since commit 69e273c0b0a3c337a521d083374c918dc52c666f:
Linux 3.17-rc3 (2014-08-31 18:23:04
On Thu, Sep 4, 2014 at 10:27 AM, Will Deacon wrote:
> On Thu, Sep 04, 2014 at 06:23:42PM +0100, Kees Cook wrote:
>> On Thu, Sep 4, 2014 at 10:03 AM, Will Deacon wrote:
>> > Hi Kees,
>> >
>> > On Wed, Sep 03, 2014 at 10:57:04PM +0100, Kees Cook wrote:
>> >> This is used from set_fixmap() and
On 2014-09-05 13:50:06 [+0200], Arnd Bergmann wrote:
> On Friday 05 September 2014 07:53:16 Weike Chen wrote:
> >
> > - irq_set_chained_handler(irq, dwapb_irq_handler);
> > - irq_set_handler_data(irq, gpio);
> > + if (!pp->irq_shared) {
> > + irq_set_chained_handler(pp->irq,
On Fri, Sep 5, 2014 at 12:25 PM, David Miller wrote:
>
> I thought the retention of RCU locking was reasonable, and that your
> feedback was something I disagreed with.
>
> This is different from ignoring your feedback.
The point is we don't need to backport the patch that far, as I already
Intel IA32 SDM Table 15-14 defines channel 0xf as 'not specified', but
EDAC doesn't know about this and returns and INTERNAL ERROR when the
channel is greater than NUM_CHANNELS:
kernel: [ 1538.886456] CPU 0: Machine Check Exception: 0 Bank 1:
949f
kernel: [ 1538.886669] TSC
The omap needs a DMA request pending right away. If it is enqueued once
the bytes are in the FIFO then nothing will happen and the FIFO will be
later purged via RX-timeout interrupt.
This patch enqueues RX-DMA request on completion but not if it was
aborted on error. The first enqueue will happen
Sometimes the OMAP UART does not signal the DMA engine to unload the FIFO.
Usually this happens when we have >threshold bytes in the FIFO
and start the DMA transfer. It seems that in those cases the UART won't
trigger the transfer once the requested threshold is reached. In some
rare cases the
On Tue, 2 Sep 2014, Christoph Lameter wrote:
> On Tue, 2 Sep 2014, Christoph Lameter wrote:
>
> > Oww.. This is double indirection deal there. A percpu offset pointing to
> > a pointer?
> >
> > Generally the following is true (definition from
> > include/asm-generic/percpu.h that is used for ARM
Due to UART_BUG_DMA_TX the am335x has to put the first one byte into the
TX FIFO to get things going. If we get to serial8250_tx_dma() via
__dma_tx_complete() then the DMA engine just finished and the FIFO is
full and we can't put the first byte into the TX FIFO as kick start so
we leave with THRI
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/dra7.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d678152db4cb..f273e3811f75 100644
---
At least on AM335x the following problem exists: Even if the TX FIFO is
empty and a TX transfer is programmed (and started) the UART does not
trigger the DMA transfer.
After $TRESHOLD number of bytes have been written to the FIFO manually the
UART reevaluates the whole situation and decides that
After dmaengine_terminate_all() has been invoked then both DMA drivers
(edma and omap-dma) do not invoke dma_cookie_complete() to mark the
transfer as complete. This dma_cookie_complete() is performed by the
Synopsys DesignWare driver which is probably the only one that is used
by omap8250-dma and
Quoting Seth Forshee (seth.fors...@canonical.com):
> On Fri, Sep 05, 2014 at 04:48:11PM +, Serge Hallyn wrote:
> > Quoting Seth Forshee (seth.fors...@canonical.com):
> > > Update fuse to support mounts from within user namespaces. This
> > > is mostly a matter of translating uids and gids into
There is nothing to do for RPM in the RX path. If the HW goes off then it
won't assert the DMA line and the transfer won't happen. So we hope that
the HW does not go off for RX to work (DMA or PIO makes no difference
here).
For TX the situation is slightly different. RPM is enabled on
start_tx().
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the
From: Cong Wang
Date: Fri, 5 Sep 2014 12:23:37 -0700
> On Fri, Sep 5, 2014 at 12:12 PM, Hannes Frederic Sowa
> wrote:
>>
>> What games are you playing? You know how patches are processed by David
>> and I even let him the choice by pointing out a problem in your patch so
>> that you could an
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior
---
arch/arm/boot/dts/am33xx.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 3a0a161342ba..078a760a4a21 100644
---
On 09/05/2014 03:05 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
>> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
[cut]
>>>
>>>
>>> documentation: Record limitations of
Quoting Seth Forshee (seth.fors...@canonical.com):
> On Fri, Sep 05, 2014 at 05:05:09PM +, Serge Hallyn wrote:
> > Quoting Seth Forshee (seth.fors...@canonical.com):
> > > Filesystem uids which don't map into a user namespace may result
> > > in inode->i_uid being INVALID_UID. A symlink and
On Fri, Aug 08, 2014 at 03:45:32PM -0400, Murali Karicheri wrote:
> Keystone PCI controller has a limitation that memory read request
> size must not exceed 256 bytes. This is a hardware limitation and
> add a quirk to force this limit on all downstream devices by
> updating mrrs.
>
>
On Fri, Sep 5, 2014 at 12:12 PM, Hannes Frederic Sowa
wrote:
>
> What games are you playing? You know how patches are processed by David
> and I even let him the choice by pointing out a problem in your patch so
> that you could an update and send v2.
I assume David goes over all the discussion
From: Cong Wang
Date: Fri, 5 Sep 2014 11:58:31 -0700
> On Fri, Sep 5, 2014 at 11:53 AM, David Miller wrote:
>> From: Sabrina Dubroca
>> Date: Tue, 2 Sep 2014 10:29:29 +0200
>>
>>> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
>>> triggers the assertion in
On Fri, 5 Sep 2014, Florian Fainelli wrote:
> On 09/05/2014 02:05 AM, Mark Rutland wrote:
> > +- brcm,irq-can-wake: if present, this means the L2 controller can be
> > used as a
> > + wakeup source for system suspend/resume.
> >>>
> >>> How variable is this?
> >>
> >> There's two
On 09/05/14 19:03, Yinghai Lu wrote:
> On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek wrote:
>> On 09/05/14 07:47, Anders Darander wrote:
>> In other words, the rounding up of the kernel will be undone in a
>> "somewhat higher level" driver in the firmware, and the request size
>> that reaches
From: Hayes Wang
Date: Thu, 4 Sep 2014 16:15:40 +0800
> If the interface has invalid MAC address, it couldn't
> be used. In order to let it work normally, give a
> random one.
>
> v3:
> Remove
> ether_addr_copy(dev->perm_addr, dev->dev_addr);
>
> v2:
> Use "%pM" format specifier for
On Fr, 2014-09-05 at 11:58 -0700, Cong Wang wrote:
> On Fri, Sep 5, 2014 at 11:53 AM, David Miller wrote:
> > From: Sabrina Dubroca
> > Date: Tue, 2 Sep 2014 10:29:29 +0200
> >
> >> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
> >> triggers the assertion in
On Fri, Sep 05, 2014 at 11:59:26AM -0700, Guenter Roeck wrote:
> On Fri, Sep 05, 2014 at 06:03:42PM +0100, Steven Honeyman wrote:
> > Add support for the Dell Latitude E6540 which needs a different fan speed
> > multiplier.
> >
> > Signed-off-by: Steven Honeyman
>
> Looks good.
>
>
On Fri, Sep 05, 2014 at 11:23:22AM -0700, K. Y. Srinivasan wrote:
> This is a win8 feature that has been implemented. Turn on the feature bit
> to enable the feature.
What does those two sentances even mean?
> With this feature turned on,
What is "this"?
> when the host is waiting
> for space
On Fri, 5 Sep 2014, Andrew Bresticker wrote:
> Instead of using GIC interrupt 0 for the timer (which was not even
> handled correctly by the GIC irqchip code and could conflict with an
> actual external interrupt), use the designated local interrupt for
> the GIC timer.
>
> Also, since the timer
From: Hannes Frederic Sowa
Date: Tue, 2 Sep 2014 22:53:44 +0200
> From: Daniel Borkmann
>
> With eBPF getting more extended and exposure to user space is on it's way,
> hardening the memory range the interpreter uses to steer its command flow
> seems appropriate. This patch moves the to be
Tony noticed that the old omap-serial driver picked the uart "number"
based on the hint given from device tree or platform device's id.
The 8250 based omap driver doesn't do this because the core code does
not honour the ->line argument which is passed by the driver.
This patch aims to keep the
On Fri, Sep 05, 2014 at 02:50:31PM -0400, Peter Hurley wrote:
> On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> > On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
> >> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
> >>> On 09/04/2014 05:59 PM, Peter Hurley wrote:
>
Applicable for 3.14-stable only.
This commit drops duplicate declaration of struct usb_functionfs_descs_head
erronousely added in commit 28c5980b54 ("usb: gadget: f_fs: resurect
usb_functionfs_descs_head structure").
Fix from 28c5980b54 is applicable only for v3.15-rc1 and newer kernels.
This
While comparing the OMAP-serial and the 8250 part of this I noticed that
the latter does not use run time-pm. Here are the pieces. It is
basically a get before first register access and a last_busy + put after
last access. This has to be enabled from userland _and_ UART_CAP_RPM is
required for
The serial8250_do_startup() function unconditionally clears the
interrupts and for that it reads from the RX-FIFO without checking if
there is a byte in the FIFO or not. This works fine on OMAP4+ HW like
AM335x or DRA7.
OMAP3630 ES1.1 (which means probably all OMAP3 and earlier) does not like
On Fri, 5 Sep 2014, Andrew Bresticker wrote:
> static void gic_mask_irq(struct irq_data *d)
> {
> - GIC_CLR_INTR_MASK(d->irq - gic_irq_base);
> + unsigned int irq = d->irq - gic_irq_base;
> +
> + if (gic_is_local_irq(irq)) {
> + GICWRITE(GIC_REG(VPE_LOCAL, GIC_VPE_RMASK),
Right now it is possible that serial8250_tx_dma() fails and returns
-EBUSY. The caller (serial8250_start_tx()) will then enable
UART_IER_THRI which will generate an interrupt once the TX FIFO is
empty.
In serial8250_handle_irq() nothing will happen because up->dma is set
and so
serial8250_do_startup() adds UART_IER_RDI and UART_IER_RLSI to ier.
serial8250_stop_rx() should remove both.
This is what the serial-omap driver has been doing and is now moved to
the 8250-core since it does no look to be *that* omap specific.
Cc: heikki.kroge...@linux.intel.com
Signed-off-by:
This patch provides a 8250-core based UART driver for the internal OMAP
UART. The long term goal is to provide the same functionality as the
current OMAP uart driver and DMA support.
I tried to merge omap-serial code together with the 8250-core code.
There should should be hardly a noticable
This is my complete queue fo the omap serial driver based on the 8250 core
code. I played with it on beagle bone, am335x-evm and dra7xx including DMA.
The runtime-pm pieces look now bug-compatible with the omap-serial driver.
Besides the runtime-om improvement I also fixed a few corner cases for
The OMAP version of the 8250 can actually use 1:1 serial8250_startup().
However it needs to be extended by a wake up irq which should to be
requested & enabled at ->startup() time and disabled at ->shutdown() time.
v2…v3: properly copy callbacks
v1…v2: add shutdown callback
Acked-by: Alan Cox
There is no way to access a struct uart_8250_port for a specific
line. This is only required outside of the 8250/uart callbacks like for
devices' suspend & remove callbacks. For those the 8250-core provides a
wrapper like serial8250_unregister_port() which passes the struct
to the proper function
The OMAP UART provides support for HW assisted flow control. What is
missing is the support to throttle / unthrottle callbacks which are used
by the omap-serial driver at the moment.
This patch adds the callbacks. It should be safe to add them since they
are only invoked from the serial_core
On Friday 05 September 2014 14:33:54 Murali Karicheri wrote:
> > This looks like it's a shared register of some sort that doesn't
> > really belong into the registers of a particular port. Could it
> > be that it's actually for the PHY?
> >
> This a shared device configuration register between the
On Fri, Sep 05, 2014 at 05:05:09PM +, Serge Hallyn wrote:
> Quoting Seth Forshee (seth.fors...@canonical.com):
> > Filesystem uids which don't map into a user namespace may result
> > in inode->i_uid being INVALID_UID. A symlink and its parent
> > could have different owners in the filesystem
On Fri, Sep 5, 2014 at 12:34 PM, Arnd Bergmann wrote:
> On Friday 05 September 2014 20:20:44 Thomas Petazzoni wrote:
>> Hum, I think I would actually prefer something like:
>>
>> if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
>> rtype = IORESOURCE_IO;
>>
On Fri, Sep 05, 2014 at 06:03:42PM +0100, Steven Honeyman wrote:
> Add support for the Dell Latitude E6540 which needs a different fan speed
> multiplier.
>
> Signed-off-by: Steven Honeyman
Looks good.
Reviewed-by: Guenter Roeck
Greg / Arnd, can you pick this up directly, or should I send
a
On Fri, Sep 5, 2014 at 11:53 AM, David Miller wrote:
> From: Sabrina Dubroca
> Date: Tue, 2 Sep 2014 10:29:29 +0200
>
>> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
>> triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()
>>
>> ipv6_sock_ac_join(),
From: Sabrina Dubroca
Date: Tue, 2 Sep 2014 10:29:29 +0200
> Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
> triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()
>
> ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to
> take RTNL before
On Fri, 5 Sep 2014, Andrew Bresticker wrote:
> For platforms which boot with device-tree and use the MIPS CPU interrupt
> controller binding, a generic plat_irq_dispatch() can be used since all
> CPU interrupts should be mapped through the CPU IRQ domain. Implement a
> plat_irq_dispatch() which
From: Andy King
Date: Tue, 2 Sep 2014 13:13:44 -0700
> We should check if the map of the table actually succeeds, and also free
> resources accordingly.
>
> Version bumped to 1.2.1.0
>
> Acked-by: Shelley Gong
> Acked-by: Bhavesh Davda
> Signed-off-by: Andy King
> Reported-by: Tetsuo Handa
On 09/05/2014 02:09 PM, Paul E. McKenney wrote:
> On Fri, Sep 05, 2014 at 08:16:48PM +1200, Michael Cree wrote:
>> On Thu, Sep 04, 2014 at 07:08:48PM -0700, H. Peter Anvin wrote:
>>> On 09/04/2014 05:59 PM, Peter Hurley wrote:
I have no idea how prevalent the ev56 is compared to the ev5.
On 09/05/2014 03:50 AM, Mikko Perttunen wrote:
Hi again!
I have fixed all other issues mentioned apart from this one. I can see
three ways ahead:
1) Keep things as is. There is a slight possibility that in the future
we will have a hardware configuration with multiple bus addresses and
this
On Fri, Sep 05, 2014 at 08:02:24PM +0400, Dmitry Voytik wrote:
> Variable cmd_name must be initialised as variable name is.
Why? What bug does this fix? Have you tested this change? Does this
cause binder to now act differently than before?
thanks,
greg k-h
--
To unsubscribe from this list:
Am 05.09.2014 20:33, schrieb Kent Overstreet:
On Fri, Sep 05, 2014 at 11:10:13AM -0600, Jens Axboe wrote:
On 09/05/2014 11:03 AM, Arne Wiebalck wrote:
On Sep 5, 2014, at 6:41 PM, Peter Kieser
wrote:
On 2014-09-05 8:37 AM, Eddie Chapman wrote:
On 05/09/14 15:17, Jens Axboe wrote:
From: "Palik, Imre"
If the drbd backing device is a new device mapper device (e.g., a
dm-linear mapping of an existing block device that contains data), the
counters are initially 0 even though the device contains useful
data. This causes throttling until something accesses the drbd device
or
Each year, the Linux Foundation's Technical Advisory Board seeks an
organizing committee for the annual Linux Plumbers Conference. That
process has now begun for the 2015 event, which will be held during the
week of August 17-21 in Seattle, Washington, alongside the LinuxCon North
America event.
On Friday 05 September 2014 20:20:44 Thomas Petazzoni wrote:
> Hum, I think I would actually prefer something like:
>
> if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_IO)
> rtype = IORESOURCE_IO;
> else if (DT_FLAGS_TO_TYPE(flags) == DT_TYPE_MEM32)
On 09/05/2014 01:54 PM, Arnd Bergmann wrote:
On Friday 05 September 2014 13:39:42 Murali Karicheri wrote:
+
/* enable RC mode in devcfg */
val = readl(reg_p);
- val&= ~PCIE_MODE_MASK;
- val |= PCIE_RC_MODE;
+ port_id<<= 1;
+ val&= ~(PCIE_MODE_MASK<<
On Fri, 5 Sep 2014, Paolo Bonzini wrote:
> Il 05/09/2014 17:14, Thomas Gleixner ha scritto:
> > So that means the code is correct. Now where is the bug?
>
> In kernel/time/timekeeping.c?
>
> We know that we should have
>
> base_mono = wall_to_monotonic + xtime_sec
>
>
201 - 300 of 1674 matches
Mail list logo
