)
[ 3114.545000] Modules linked in:
[ 3114.545717] CPU: 18 PID: 30217 Comm: trinity-c617 Tainted: GW
3.17.0-rc4-next-20140910-sasha-00032-g6825fb5-dirty #1137
[ 3114.548058] task: 88041505 ti: 88076f584000 task.ti:
88076f584000
[ 3114.549284] RIP: 0010:[] []
chan
On Tue, Sep 09, 2014 at 10:44:51AM +0200, Robert Baldyga wrote:
> Hi,
>
> I have splitted my patchset "usb: dwc2/gadget: fix series" into two series.
> This patch series contains improvements for dwc2/gadget driver. It's intended
> for 3.18.
>
> Andrzej Pietrasiewicz (1):
> usb: dwc2/gadget:
On 09/09/2014 10:52 AM, Mel Gorman wrote:
> Since 2.6.24 there has been a paranoid check in move_freepages that looks
> up the zone of two pages. This is a very slow path and the only time I've
> seen this bug trigger recently is when memory initialisation was broken
> during patch development.
On Wed, 10 Sep 2014, Xiubo Li wrote:
So you add BE/LE APIs according to the subject line, but you fail
again to tell WHY. If that would be the only issue
> Signed-off-by: Xiubo Li
> ---
> drivers/clocksource/mmio.c | 44
> 1 file changed, 44
On Wed, Sep 10, 2014 at 10:16:03AM +0100, Mel Gorman wrote:
> On Tue, Sep 09, 2014 at 12:53:18PM -0700, Andrew Morton wrote:
> > On Mon, 8 Sep 2014 12:57:18 +0100 Mel Gorman wrote:
> >
> > > zone_page_state is an API hazard because of the difference in behaviour
> > > between SMP and UP is very
On Wed, Sep 10, 2014 at 1:14 PM, H. Peter Anvin wrote:
> On 09/10/2014 12:30 PM, Toshi Kani wrote:
>>
>> When WT is unavailable due to the PAT errata, it does not fail but gets
>> redirected to UC-. Similarly, when PAT is disabled, WT gets redirected
>> to UC- as well.
>>
>
> But on pre-PAT
2014-09-10 20:16 GMT+04:00 Christoph Lameter :
> On Wed, 10 Sep 2014, Andrey Ryabinin wrote:
>
>> virt_to_obj takes kmem_cache address, address of slab page,
>> address x pointing somewhere inside slab object,
>> and returns address of the begging of object.
>
> This function is SLUB specific.
On Wed, Sep 10, 2014 at 1:12 PM, Toshi Kani wrote:
> On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
>> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then
>> > change
>> > +a specific range to wt with
2014-09-10 19:46 GMT+04:00 Dave Hansen :
> Overall, the approach here looks pretty sane. As you noted, it would be
> nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
> me. The use of the vmemmap code looks to be a nice fit.
>
> Few nits below.
>
> On 09/10/2014 07:31 AM,
On Mon, Sep 8, 2014 at 4:29 PM, Cong Wang wrote:
> On Mon, Sep 8, 2014 at 4:42 PM, Rafael J. Wysocki wrote:
>> On Monday, September 08, 2014 04:16:15 PM Cong Wang wrote:
>>> On Mon, Sep 8, 2014 at 4:23 PM, Rafael J. Wysocki
>>> wrote:
>>> >
>>> > The reason why it matters for the suspend-time
On Wed, 2014-09-10 at 11:30 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
> > +Drivers may map the entire NV-DIMM range with ioremap_cache and then change
> > +a specific range to wt with set_memory_wt.
>
> That's mighty specific :)
How about below?
Drivers
>> right, use that to call phy_init() at the right time, then you need to
>> add a new ->calibrate() method which, likely, will only be used by you
>> ;-)
> so you mean, the xhci should itself call phy_init() at a time suitable,
> so that ->calibrate() is not required at all ?
I'm not sure if
On Wed, Sep 10, 2014 at 11:22 AM, Andy Lutomirski wrote:
>>
>>attr is a pointer to a union of type bpf_attr as defined below.
>>
>>size is the size of the union.
>
> I find this strange. Why not just make attr be a pointer to the
> relevant struct for the operation being
On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:
>
> I think the whole "removing Alpha EV5" support is basically bonkers. Just
> use set_bit in the tty layer. Alpha will continue to work as well as it
> always has done and you won't design out support for any future processor
> that turns out
On 09/10/2014 12:30 PM, Toshi Kani wrote:
>
> When WT is unavailable due to the PAT errata, it does not fail but gets
> redirected to UC-. Similarly, when PAT is disabled, WT gets redirected
> to UC- as well.
>
But on pre-PAT hardware you can still do WT.
-hpa
--
To unsubscribe from
On Wed, 10 Sep 2014 10:13:54 +0100
Lee Jones wrote:
> I think adding ACPI support should be in its own patch.
Agree with the rest reviews comments. On this one, I agree I should
take out the non-essential part of the ACPI code. i.e. mfd cell
device for acpi opregion handler driver. Let it be
On Wed, Sep 10, 2014 at 12:40 PM, Toshi Kani wrote:
> On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
>> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
> :
>> > +#ifndef ARCH_HAS_IOREMAP_WT
>> > +#define ioremap_wt ioremap_nocache
>> > +#endif
>> > +
>>
>> This is a little bit
On Wed, 10 Sep 2014, Jiang Liu wrote:
> On 2014/9/9 20:37, Thomas Gleixner wrote:
> >> + ret = mp_ioapic_registered(gsi_base);
> >> + up_write(_ioapic_rwsem);
> >> +
> >> + return ret;
> >> +}
> >
> > So I assume that this is for a particular caller in the apci ioapic
> > hotplug code and
On Wed, 10 Sep 2014, Jiang Liu wrote:
> >> int mp_register_ioapic(int id, u32 address, u32 gsi_base,
> >> @@ -3867,8 +3873,15 @@ int mp_register_ioapic(int id, u32 address, u32
> >> gsi_base,
> >>}
> >>for_each_ioapic(ioapic)
> >>if (ioapics[ioapic].mp_config.apicaddr ==
Hi,
http://patchwork.ozlabs.org/patch/359069/
https://lkml.org/lkml/2014/6/12/186
Will the patch ever included to linux-next?
pwm_config() API could be extended to support
not only period [ns] and duty [ns] time
but also frequency [Hz] and duty cycle fraction [1/1000?]
(instead of time in ns)
parse_arg() has three possible return values:
-EINVAL if sscanf(), in short, fails;
zero if "count" is zero; and
"count" in all other cases
But "count" will never be zero. See, parse_arg() is called by the
various store functions. And the callchain of these functions starts
with
From: Or Gerlitz
Date: Wed, 10 Sep 2014 10:42:41 +0300
> Hi Chuck, thanks for bisecting this out. Indeed, as of this kernel 3.2
> commit 936d7de "IPoIB: Stop lying about hard_header_len and use
> skb->cb to stash LL addresses" we are using the skb->cb field to
> enable proper work under GRO and
On 9/10/2014 12:53 PM, Guenter Roeck wrote:
On Wed, Sep 10, 2014 at 12:02:08PM -0500, Aravind Gopalakrishnan wrote:
Fam16h,M30h(Mullins) and Fam15hM30h(Kaveri) processors can
report 'power_crit' value. So, adding their respective device ids.
Also, according to BKDGs, the 'TdpRunAvgAccCap' that
Javier,
On Wed, Sep 10, 2014 at 3:19 AM, Javier Martinez Canillas
wrote:
> From: Vivek Gautam
>
> Enabled MAX77802 pmic for exynos systems.
> One config USB_ANNOUNCE_NEW_DEVICES to display device
> information on connect.
> Another config for I2C_CHARDEV to see i2c device nodes.
>
>
Javier,
On Wed, Sep 10, 2014 at 3:19 AM, Javier Martinez Canillas
wrote:
> The downstream ChromeOS 3.8 kernel sets the clock frequency
> for the I2C bus 7 at 400kHz. Do the same change in mainline.
>
> Suggested-by: Doug Anderson
> Signed-off-by: Javier Martinez Canillas
> ---
>
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
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
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
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
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
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().
Cc: devicet...@vger.kernel.org
Reviewed-by: Tony Lindgren
Tested-by: Tony Lindgren
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
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
On 09/10/2014 03:33 PM, Sebastian Andrzej Siewior wrote:
> I noticed that the serial8250_tx_dma() is invoked sometimes while
> uart_circ_empty() says that the buffer is empty.
>
> I tracked one occuring down to:
>
> n_tty_write()
>=> O_OPOST(tty))
> => the while loop did
On 09/10/2014 01:35 PM, Elliott, Robert (Server Storage) wrote:
>
>
>> -Original Message-
>> From: Jens Axboe [mailto:ax...@kernel.dk]
>> Sent: Wednesday, 10 September, 2014 1:15 PM
>> To: Robert Elliott; Elliott, Robert (Server Storage); h...@lst.de;
>> linux-kernel@vger.kernel.org
>>
On Wed, Sep 10, 2014 at 07:32:36PM +0200, Stefan Wahren wrote:
> Am 10.09.2014 17:13, schrieb Mark Brown:
> >Ugh, this looks like it might be a regulator driver but since the
> >subject line was "ARM: " I deleted it unread - if your changelog looks
> >different to all the other changelogs in the
On Wed, 2014-09-10 at 11:29 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
:
> > +#ifndef ARCH_HAS_IOREMAP_WT
> > +#define ioremap_wt ioremap_nocache
> > +#endif
> > +
>
> This is a little bit sad. I wouldn't be too surprised if there are
> eventually users
Will,
On Wed, Sep 10, 2014 at 11:46 AM, Will Deacon wrote:
> On Wed, Sep 10, 2014 at 07:09:59PM +0100, Doug Anderson wrote:
>> On Wed, Sep 10, 2014 at 10:34 AM, Will Deacon wrote:
>> > Setting aside the security model, booting in secure mode can also have a
>> > significant impact on the
Use newly-introduced tty->flow_lock to serialize updates to
tty->flow_stopped (via tcflow()) and with concurrent tty flow
control changes from other sources.
Merge the storage for ->stopped and ->flow_stopped, now that both
flags are serialized by ->flow_lock.
The padding bits are necessary to
When a master pty is set to packet mode, flow control changes to
the slave pty cause notifications to the master pty via reads and
polls. However, these tests are occurring for all ttys, not
just ptys.
Implement flow control packet mode notifications in the pty driver.
Only the slave side
While transmitting a START/STOP char for tcflow(TCION/TCIOFF), prevent
a termios change. Otherwise, a garbage in-band flow control char
may be sent, if the termios change overlaps the transmission setup.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_ioctl.c | 10 +++---
1 file changed, 7
This patch fixes the following sparse warnings:
CHECK drivers/staging/rtl8188eu/hal/fw.c
drivers/staging/rtl8188eu/hal/fw.c:219:13: warning: cast to restricted
__le16
drivers/staging/rtl8188eu/hal/fw.c:219:13: warning: cast to restricted
__le16
drivers/staging/rtl8188eu/hal/fw.c:219:13:
Relocate the file-scope function, send_prio_char(), as a global
helper tty_send_xchar(). Remove the global declarations for
tty_write_lock()/tty_write_unlock(), as these are file-scope only now.
Signed-off-by: Peter Hurley
---
drivers/tty/tty_io.c| 33 +++--
The Alpha EV4/EV5 cpus can corrupt adjacent byte and short data because
those cpus use RMW to store byte and short data. Thus, concurrent adjacent
byte stores could become corrupted, if serialized by a different lock.
tty_struct uses different locks to protect certain fields within the
structure,
From: Joe Perches
Date: Tue, 9 Sep 2014 21:17:27 -0700
> Remove remaining uses of pr_warning in net/
>
> Joe Perches (5):
> atm: Convert pr_warning to pr_warn
> ceph: Convert pr_warning to pr_warn
> pktgen: Convert pr_warning to pr_warn
> iucv: Convert pr_warning to pr_warn
>
On Wed, 2014-09-10 at 20:35 +0100, Jonathan Cameron wrote:
> On 02/09/14 10:30, Laurentiu Palcu wrote:
> > The following chips are either similar or have only the resolution
> > different. Hence, change this driver to support these chips too:
> >
> > BMI055 - combo chip (accelerometer part is
On Wed, 2014-09-10 at 11:26 -0700, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
> > This patch changes reserve_memtype() to handle the WT cache mode.
> > When PAT is not enabled, it continues to set UC- to *new_type for
> > any non-WB request.
> >
> > When a target
On Wed, Sep 10, 2014 at 06:53:56PM +0300, Dan Carpenter wrote:
> On Wed, Sep 10, 2014 at 05:28:11PM +0200, Jiri Kosina wrote:
> >
> > Too late for this now, yes.
>
> We could still introduce a __kfree_fast_path() which doesn't have
> checking.
Well, there certainly is precedence for that sort
With 8250-dma, 8250-omap and am335x I observe the following:
- start a RX transfer which will finish once the FIFO has enough data
- The TX side starts a large TX transfer, say 1244 bytes. It takes approx
102ms for the transfer to complete
- cancel the RX transfer & start the RX transfer a few
On Wed, 10 Sep 2014, Mel Gorman wrote:
> On Tue, Sep 09, 2014 at 07:45:26PM -0700, Hugh Dickins wrote:
> >
> > I've been rather assuming that the 9d340902 seen in many of the
> > registers in that Aug26 dump is the pte val in question: that's
> > SOFT_DIRTY|PROTNONE|RW.
The 900s in the latest
On Wed, Sep 10, 2014 at 06:59:20PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20140909:
>
> New tree: powerpc-merge-mpe
>
> The pm tree gained conflicts against the mvebu and arm-soc trees.
>
> The v4l-dvb tree still had its build failure so I used the version from
>
On Wed, Sep 10, 2014 at 10:28 PM, Jonathan Cameron wrote:
> On 10/09/14 18:57, Hartmut Knaack wrote:
>> Daniel Baluta schrieb, Am 10.09.2014 08:57:
>>> Minimal implementation. This driver provides raw illuminance readings.
>>>
>>> This is based on drivers/hwmon/al3320.c (*) driver from msm tree
> -Original Message-
> From: Jens Axboe [mailto:ax...@kernel.dk]
> Sent: Wednesday, 10 September, 2014 1:15 PM
> To: Robert Elliott; Elliott, Robert (Server Storage); h...@lst.de;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] block: default to rq_affinity=2 for blk-mq
>
> On
On 02/09/14 10:30, Laurentiu Palcu wrote:
> The following chips are either similar or have only the resolution
> different. Hence, change this driver to support these chips too:
>
> BMI055 - combo chip (accelerometer part is identical to BMC150's)
> BMA255 - identical to BMC150's accelerometer
On Wed, Sep 10, 2014 at 03:28:10PM -0400, Jeff Layton wrote:
> Yes, that's the downside of moving to multiple list_heads. Still, I
> think it's worth doing that even if we end up with the code a bit more
> verbose.
>
> It may be best to consider moving some of this into helpers that live
> in
I noticed that the serial8250_tx_dma() is invoked sometimes while
uart_circ_empty() says that the buffer is empty.
I tracked one occuring down to:
n_tty_write()
=> O_OPOST(tty))
=> the while loop did something but neither tty's ->write()
nor its
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
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 diff of v8…v9 is small:
- rebased on top's of Greg's tty-next branch
- fixed #10 where we might have THRE interrupt enabled for longer than
needed
- re-did register setup in #10. Before this "less file" could freeze the
am335x-evm.
Sebastian
--
To unsubscribe from this list: send the
On 02/09/14 11:30, Laurentiu Palcu wrote:
> On Mon, Sep 01, 2014 at 08:51:36AM -0700, Srinivas Pandruvada wrote:
>> On Mon, 2014-09-01 at 08:36 -0700, Joe Perches wrote:
>>> On Mon, 2014-09-01 at 12:11 +0300, Laurentiu Palcu wrote:
The following chips are either similar or have only the
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
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 Tue, 9 Sep 2014, Weike Chen wrote:
> The Synopsys DesignWare APB GPIO driver only supports open firmware devices.
> But, like Intel Quark X1000 SOC, which has a single PCI function exporting
> a GPIO and an I2C controller, it is a Multifunction device. This patch is
> to enable the current
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
Reviewed-by: Tony
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
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
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
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 10/09/14 18:57, Hartmut Knaack wrote:
> Daniel Baluta schrieb, Am 10.09.2014 08:57:
>> Minimal implementation. This driver provides raw illuminance readings.
>>
>> This is based on drivers/hwmon/al3320.c (*) driver from msm tree written
>> by Tsechih Lin
>>
>> *
On Wed, 10 Sep 2014 15:17:34 -0400
"J. Bruce Fields" wrote:
> On Wed, Sep 10, 2014 at 10:28:46AM -0400, Jeff Layton wrote:
> > Signed-off-by: Jeff Layton
> > ---
> > fs/nfs/delegation.c | 37 +
> > fs/nfs/nfs4state.c | 24 +++-
> >
On Wed, Sep 10, 2014 at 03:17:34PM -0400, J. Bruce Fields wrote:
> On Wed, Sep 10, 2014 at 10:28:46AM -0400, Jeff Layton wrote:
> > Signed-off-by: Jeff Layton
> > ---
> > fs/nfs/delegation.c | 37 +
> > fs/nfs/nfs4state.c | 24 +++-
> >
On Wed, Sep 10, 2014 at 01:28:56PM +0200, Maciej Matraszek wrote:
> +static int pm_genpd_summary_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, pm_genpd_summary_show, inode->i_private);
On Wed, Sep 10, 2014 at 10:28:46AM -0400, Jeff Layton wrote:
> Signed-off-by: Jeff Layton
> ---
> fs/nfs/delegation.c | 37 +
> fs/nfs/nfs4state.c | 24 +++-
> fs/nfs/pagelist.c | 3 ++-
> fs/nfs/write.c | 39
Hi Kever,
Am Mittwoch, 10. September 2014, 18:05:53 schrieb Kever Yang:
> basic rk3288 smp support
>
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Kever Yang
> ---
>
> arch/arm/mach-rockchip/core.h| 1 +
> arch/arm/mach-rockchip/platsmp.c | 60
>
On 09/10/2014 11:26 AM, Andy Lutomirski wrote:
> On Wed, Sep 10, 2014 at 9:51 AM, Toshi Kani wrote:
>> This patch changes reserve_memtype() to handle the WT cache mode.
>> When PAT is not enabled, it continues to set UC- to *new_type for
>> any non-WB request.
>>
>> When a target range is RAM,
Rob Clark reports a sleeping while atomic bug when using perf.
BUG: sleeping function called from invalid context at
../kernel/locking/mutex.c:583
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
[ cut here ]
WARNING: CPU: 2 PID: 4828 at
On Wed, 10 Sep 2014, Sasha Levin wrote:
> On 09/09/2014 10:45 PM, Hugh Dickins wrote:
> > Sasha, you say you're getting plenty of these now, but I've only seen
> > the dump for one of them, on Aug26: please post a few more dumps, so
> > that we can look for commonality.
>
> I wasn't saving older
The serial core uses the tty port flags, ASYNC_CTS_FLOW and
ASYNC_CD_CHECK, to track whether CTS and DCD changes should be
ignored or handled. However, the tty port flags are not safe for
atomic bit operations and no lock provides serialized updates.
Introduce the struct uart_port status field to
uart_set_termios() is called with interrupts enabled; no need to
save and restore the interrupt state when taking the uart port lock.
Signed-off-by: Peter Hurley
---
drivers/tty/serial/serial_core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
The serial core provides two helper functions, uart_handle_dcd_change()
and uart_handle_cts_change(), for UART drivers to use at interrupt
time. The serial core expects the UART driver to hold the uart port lock
when calling these helpers to prevent state corruption.
If lockdep enabled, trigger a
The stopped, hw_stopped, flow_stopped and packet bits are smp-unsafe
and interrupt-unsafe. For example,
CPU 0 | CPU 1
|
tty->flow_stopped = 1 | tty->hw_stopped = 0
One of these updates will be corrupted, as the bitwise operation
on
ISDN4Linux always enables CTS flow control and does not use the
tty_port_cts_enabled() helper function; remove ASYNC_CTS_FLOW
state enable/disable.
cc: Karsten Keil
cc:
Signed-off-by: Peter Hurley
---
drivers/isdn/i4l/isdn_tty.c | 5 -
1 file changed, 5 deletions(-)
diff --git
tty->hw_stopped is not used by the tty core and is thread-unsafe;
hw_stopped is a member of a bitfield whose fields are updated
non-atomically and no lock is suitable for serializing updates.
Replace serial core usage of tty->hw_stopped with uport->hw_stopped.
Use int storage which works around
Hi Greg,
Changes since v1:
1. Omits v1 patches 1-12 which you already applied
2. Depends on 'locking: Add WARN_ON_ONCE lock assertion',
which replaces v1 patch 13
3. Works around Alpha EV4/5 non-atomic byte/short storage
4. Works around gcc bug in versions < 4.7.2, where bitfield stores can
Commit 64851636d568ae9f167cd5d1dcdbfe17e6eef73c,
serial: bfin-uart: Remove ASYNC_CTS_FLOW flag for hardware automatic CTS,
open-codes uart_handle_cts_change() when CONFIG_SERIAL_BFIN_HARD_CTSRTS
to skip start and stop tx.
But the CTS interrupt handler _still_ calls uart_handle_cts_change();
only
Without serialization, the flow control state can become inverted
wrt. the actual hardware state. For example,
CPU 0 | CPU 1
stop_tty() |
lock ctrl_lock |
tty->stopped = 1 |
unlock ctrl_lock |
The tty core does not test tty->hw_stopped; remove from drivers
which don't test it themselves.
cc: Johan Hovold
Signed-off-by: Peter Hurley
---
drivers/usb/serial/digi_acceleport.c | 7 +--
drivers/usb/serial/io_ti.c| 7 +--
drivers/usb/serial/ti_usb_3410_5052.c | 7
pte = pte_mkwrite(pte);
> + }
> #ifdef CONFIG_HUGETLB_PAGE
> if (PageHuge(new)) {
> pte = pte_mkhuge(pte);
I seem to have hit this warning:
[ 4782.617806] WARNING: CPU: 10 PID: 21180 at mm/migrate.c:155
remove_migration_pte+0x3f7/0x420()
[ 4782.619315] M
On 03/09/14 11:13, Heiko Stübner wrote:
> Am Mittwoch, 3. September 2014, 00:20:58 schrieb Hartmut Knaack:
>> Heiko Stübner schrieb:
>>> Older Rockchip SoCs, at least the rk3066, used a slightly modified saradc
>>> for temperature measurements. This so called tsadc does not contain any
>>> active
On Tue, 9 Sep 2014, Mel Gorman wrote:
> Since 2.6.24 there has been a paranoid check in move_freepages that looks
> up the zone of two pages. This is a very slow path and the only time I've
> seen this bug trigger recently is when memory initialisation was broken
> during patch development.
On Wed, Sep 10, 2014 at 09:40:11AM +0800, Ming Lei wrote:
> I am wondering we can do that because lifetime is totally different
> between flush requests and tag_set requests which are initialized
> before request queue is created.
We shouldn't do it in the tag sets, but where we allocate and free
Hi Stefan,
On Wed, Sep 10, 2014 at 2:32 PM, Stefan Wahren wrote:
> Hi Mark,
>
> Am 10.09.2014 17:13, schrieb Mark Brown:
>>
>> On Wed, Sep 10, 2014 at 03:18:53PM +0100, Mark Rutland wrote:
>>>
>>> On Tue, Sep 09, 2014 at 08:17:17PM +0100, Stefan Wahren wrote:
>>
>>
>> Ugh, this looks like it
On Wed, Sep 10, 2014 at 11:27:44AM -0700, Andi Kleen wrote:
> > Note that since then we have actually fixed the 'cannot fault from NMI
> > context' thing, so we should be able to actually take those faults. I
> > suspect we can simply remove those WARNs from the vmalloc fault path,
> > but it
On Wed, 10 Sep 2014 14:38:15 -0400
"J. Bruce Fields" wrote:
> On Wed, Sep 10, 2014 at 10:28:39AM -0400, Jeff Layton wrote:
> > The current scheme of using the i_flock list is really difficult to
> > manage. Start conversion to a new scheme to eventually replace it.
> >
> > We start by adding a
On 09/10/14 11:21, Will Deacon wrote:
> On Tue, Sep 09, 2014 at 06:54:45PM +0100, Stephen Boyd wrote:
>
>> Here's the interdiff. Is there a reason arm64 casts data to an unsigned
>> int pointer when what's passed is an int pointer?
> There has to be a cast to something because data is a void *.
>
On Wed, Sep 10, 2014 at 07:09:59PM +0100, Doug Anderson wrote:
> On Wed, Sep 10, 2014 at 10:34 AM, Will Deacon wrote:
> > Setting aside the security model, booting in secure mode can also have a
> > significant impact on the programming model of system IP, not just the CPU.
> > For example, the
In PTE holes that contain VM_SOFTDIRTY VMAs, unmapped addresses before
VM_SOFTDIRTY VMAs are reported as softdirty by /proc/pid/pagemap. This
bug was introduced in 68b5a652485682f67eacdee3deae640fb7845b63. The
aforementioned patch made /proc/pid/pagemap look at VM_SOFTDIRTY in PTE
holes but
On Wed, Sep 10, 2014 at 10:28:39AM -0400, Jeff Layton wrote:
> The current scheme of using the i_flock list is really difficult to
> manage. Start conversion to a new scheme to eventually replace it.
>
> We start by adding a new i_flctx to struct inode. For now, it lives in
> parallel with
On Wed, Sep 10, 2014 at 10:45:33AM -0400, Peter Hurley wrote:
> On 09/10/2014 09:08 AM, Peter Zijlstra wrote:
> > On Wed, Sep 10, 2014 at 07:02:10AM -0400, Peter Hurley wrote:
> >> On 09/04/2014 01:14 AM, Ingo Molnar wrote:
> >>>
> >>> * Peter Zijlstra wrote:
> >>>
> On Wed, Sep 03, 2014 at
From: Markos Chandras
Date: Wed, 10 Sep 2014 14:23:28 +0100
> On 08/29/2014 04:33 PM, Daniel Borkmann wrote:
>> On 08/29/2014 04:23 PM, Markos Chandras wrote:
>>> MIPS supports BPF JIT since v3.16-rc1
>>>
>>> Cc: Randy Dunlap
>>> Cc: "David S. Miller"
>>> Cc: Daniel Borkmann
>>> Cc: Alexei
On Wed, Sep 10, 2014 at 08:07:24AM +0200, Johannes Thumshirn wrote:
> On Tue, Sep 09, 2014 at 05:26:35PM -0700, Greg Kroah-Hartman wrote:
> > On Tue, Sep 09, 2014 at 07:56:15AM +0200, Johannes Thumshirn wrote:
> > > On Mon, Sep 08, 2014 at 04:17:33PM -0700, Greg Kroah-Hartman wrote:
> > > > >
> >
201 - 300 of 1760 matches
Mail list logo
