The reason I mention it is because I've been mulling over something
Dirk Hohndel said during LinuxCon EU and the kernel summit. He asked
at the QA session whether we could do a release with just stability
and bug-fixes, and I pooh-poohed it because I didn't see most of us
having the attention
And the 520 doesn't claim this feature (look for enhanced power loss
protection at http://ark.intel.com/products/66248), so that wouldn't
explain these results anyway.
Correct i think intel simply ignores CMD_FLUSH on that drive - no idea
why an they fixed this for their 330, 530, DC
On Fri, 22 Nov 2013 10:59:23 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Distinguish if caller is n_tty_poll() or n_tty_read(), and
set the read/wakeup threshold accordingly.
That looks very wrong to me. The poll() and read() wakeup should always
match. In addition if MIN_CHAR is set
On Fri, 22 Nov 2013 10:59:24 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Only wakeup the _waiting_ reader, polls and/or writer(s).
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/n_tty.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
On Fri, 22 Nov 2013 10:59:25 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Instrument .receive_buf() and read() paths with trace_printk's
to aid in debugging flow control changes.
tty devices have a device, we have a dev_dbg() layer. The old tty trace
predates this but there isn't really
On Fri, 22 Nov 2013 10:59:23 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Distinguish if caller is n_tty_poll() or n_tty_read(), and
set the read/wakeup threshold accordingly.
Signed-off-by: Peter Hurley pe...@hurleysoftware.com
Doh ignore previous.. yes that patch is right. I should
7) Rescan line discipline buffer when changing from non-canonical to canonical
mode. The real problem with this approach (besides the inefficiency) is that
this
solution could break some (admittedly unknown) program that contrived to
exchange
data in non-canonical mode but read in
On Fri, 22 Nov 2013 07:16:25 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Although the maximum allowable canonical line is specified to
be 255 bytes (MAX_CANON), the practical limit has actually been
the size of the line discipline read buffer (N_TTY_BUF_SIZE == 4096).
Looks good.
On Thu, 21 Nov 2013 22:05:56 -0800
David E. Box david.e@linux.intel.com wrote:
+static int iosf_mbi_probe(struct platform_device *pdev)
+{
+ struct resource *mem;
+
+ /* Get and map MBI address space */
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
Yes, and I'm arguing that is a bug (as in, 0.01% people are using
hdparm correctly).
Generally speaking if you are using hdparm for tuning it means we need to
fix something in the ATA layer so you don't have to !
I guess it would be safer not to reattach drives after power
fail... (also I
On Sat, 23 Nov 2013 21:01:56 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
On 11/23/2013 07:26 PM, One Thousand Gnomes wrote:
On Fri, 22 Nov 2013 10:59:23 -0500
Peter Hurley pe...@hurleysoftware.com wrote:
Distinguish if caller is n_tty_poll() or n_tty_read(), and
set the read
Reported-by: Nicholas arealityfarbetw...@googlemail.com
Signed-off-by: Michele Baldessari mich...@acksyn.org
Tested-by: Nicholas arealityfarbetw...@googlemail.com
Acked-by: Alan Cox gno...@lxorguk.ukuu.org.uk
Going for a dig in google turns this up against multiple controllers,
multiple
Anyway, I really don't care either way, but this seems like something
that the drivers should be doing. What suddenly changed that caused
this problem to occur that hasn't happened in the years prior to now
that drives this to be a stable-kernel issue?
When this first went in I pointed out
I cc'd you because of your recent involvement in other
tty patches/bug fixes and because it's your FIXME comment.
Feel free to ignore and/or let me know you would prefer not to
be bothered.
It does seem horribly convoluted and likely to dig bigger long term holes
than the one its filling. The
+static int bcm_kona_wdt_set_resolution_reg(struct bcm_kona_wdt *wdt)
+{
+ uint32_t val;
+ int timeout;
+ unsigned long flags;
+ int ret = 0;
+
+ if (wdt-resolution SECWDOG_MAX_RES)
+ return -EINVAL;
+
+ spin_lock_irqsave(wdt-lock, flags);
+
+
On Wed, 13 Nov 2013 12:14:29 -0800
David Cohen david.a.co...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppusw...@linux.intel.com
Since the same ipc driver can be used by many platforms, using
macros for defining ipc_base and i2c_base addresses is not
a
On Wed, 13 Nov 2013 12:14:30 -0800
David Cohen david.a.co...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan sathyanarayanan.kuppusw...@linux.intel.com
Enabled ipc support for penwell, clovertrail tangier platforms.
At some point this really ought to be discoverable in your SFI,
O +prompt IPC access mode
+ depends on INTEL_SCU_IPC
+ default INTEL_SCU_IPC_INTR_MODE
+ ---help---
+ Select the desired access mode for IPC call.
This seems to depend at runtime on the platform so ifdefs seem
inappropriate.
static inline void ipc_command(u32 cmd) /*
My question now is, is it a bug in the driver or in the VGA Bios?
I´ve checked the VGA bios and did a hex dump but there is really no $VBT
string.
On an Atom Gen1 CPU with intel GMA500 Graphic there is the string in the VGA
BIOS.
But if i create the VGA BIOS for intel Atom E680 which has
but if you checkout the PCI table in the driver, there is the device
and vendor ID mentioned, that means for me that the driver supports
the Graphic core in E680.
And after loading the driver, it will parse for $VBT.
I just find a comment in the PCI table with E620 but
the device and vendor
On Thu, 14 Nov 2013 09:36:18 -0800
David Cohen david.a.co...@linux.intel.com wrote:
Hi Alan,
[snip]
So I think
1. Pass the informatio upon whether IRQ mode should be used in the
platform information and remove all the ifdeffery
I will double check with Sathya. But in case polling
On Thu, 14 Nov 2013 09:31:38 -0800
David Cohen david.a.co...@linux.intel.com wrote:
On 11/14/2013 05:43 AM, One Thousand Gnomes wrote:
On Wed, 13 Nov 2013 12:14:30 -0800
David Cohen david.a.co...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
sathyanarayanan.kuppusw
On Thu, 14 Nov 2013 21:39:23 +0100
Geert Uytterhoeven ge...@linux-m68k.org wrote:
To make scripts/get_maintainer.pl output something sensible.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
I guess it's orphaned, just like HFS?
Looking at bugzilla - yes
--
To unsubscribe from
+
+#define BCM_KONA_WDT_NAME bcm-kona-wdt
I just noticed that this should be bcm_kona_wdt instead.
Otherwise looks good.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
After upgrading to kernel 3.12 I noticed one issue with tmux software.
The easiest way to reproduce will be:
1. Start tmux session as root.
2. Connect via ssh and use tmux attach to attach to the running
session.
3. Kill ssh client.
You can notice that shell (zsh in my case) and tmux
if i dump the memory on 0xFC of the config space, there is just some from the
BIOS vendor with a BIOS Version, but nothing like $GCT.
Ok
In the Datasheet the 0xFC is described as storage does it mean there should
be the settings for the Graphic like VBT?
I did not find more information
I doubt this is caused by a race condition; the first hangup would do most
of the destruction regardless, and a second hangup can't really race with
the first because of the tty_lock() held for most of the hangup.
In any event, it's worth discovering what state a subsequent hangup can
On Mon, 18 Nov 2013 11:41:22 -0500 (EST)
Vince Weaver vincent.wea...@maine.edu wrote:
On Mon, 18 Nov 2013, Peter Zijlstra wrote:
On Fri, Nov 15, 2013 at 01:04:23PM -0500, Vince Weaver wrote:
(figured out the minicom issue).
Anyway while trying to reproduce the last bug I
And accessing the emergency reserves means we are definitely no longer
A-OK, this is not comparable to the first direct reclaim invocation.
We exhausted our options and we got really lucky. It should not be
considered the baseline and a user listening for OOM conditions
should be informed
This is assuming your hard drive _itself_ doesn't have bufferbloat, but
http://spritesmods.com/?art=hddhackf=rss implies they don't, and
tagged command queueing lets you see through that anyway so your
actually committed numbers could presumably still be accurate if the
manufacturers
These types of nested lock problems are common when different layers use
the same interface (the fb subsystem's use of the vt driver is another
example).
They are, and they end up nasty and eventually become impossible to fix.
Better to fix the underlying fundamental error as and when we can.
If Konrad and Boris agree that breaking the kernel's ABI in this way is
acceptable in this specific case, I'll defer to them.
My opinion as Xen on ARM hypervisor maintainer is that this is the right
thing to do in this case.
Sounds to me like the difference between product and research
Just a random thought but what about using the CONFIG_$ARCH to define a
more semantic name, like HAVE_4_BYTE_ALIGNED_QUAD_WORDS, or whichever
terminology for an 8-byte type is appropriate in the context.
Maybe Linux even already has such a #define?
It doesn't need one. It's written in GNU C
On Tue, 3 Dec 2013 15:40:37 +
Julien Grall julien.gr...@linaro.org wrote:
On ARM (32 bits and 64 bits), the double-word is 8-bytes aligned. This will
result on different structure from Xen and Linux repositories.
As Linux is using __packed__ attribute, it must have a 4-bytes padding
How does the patch ensure new kernels on existing hypervisor versions
don't break ?
As Ian said on the thread xen-block: correctly define structures in
public headers (see thread https://lkml.org/lkml/2013/12/3/155), the
ABI is not yet fixed for ARM.
And if you are one of the existing
diff --git a/drivers/acpi/reboot.c b/drivers/acpi/reboot.c
index a6c77e8b..89a181f 100644
--- a/drivers/acpi/reboot.c
+++ b/drivers/acpi/reboot.c
@@ -3,12 +3,43 @@
#include linux/acpi.h
#include acpi/reboot.h
+/*
+ * There are some rare cases in the ARM world with PCI is not one
+
On Wed, 4 Dec 2013 00:36:47 +0800
Hanjun Guo hanjun@linaro.org wrote:
_PDC related stuff in processor_core.c is little bit X86/IA64 dependent,
rework the code to make it more arch-independent.
The return value of acpi_processor_eval_pdc() should be 'acpi_status' but
defined as 'int',
O +enum idle_boot_override { IDLE_NO_OVERRIDE = 0, IDLE_HALT, IDLE_NOMWAIT,
+ IDLE_POLL, IDLE_FORCE_MWAIT };
This should probably move out of the arch directory to be a single enum
including both platforms values. That will make it rather easier to keep
sane and avoid ifdefs
itself. The protocol is defined by an entity which is external to Linux.
If this had been a bug in the IP protocol handling we would fix it and
move on. This case is no different IMHO.
Actually that is quite untrue. We are *very* careful that we can talk to
other internet nodes that speak
diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
index 45ff625..8527ecc 100644
--- a/drivers/acpi/plat/arm-core.c
+++ b/drivers/acpi/plat/arm-core.c
@@ -58,6 +58,13 @@ EXPORT_SYMBOL(acpi_pci_disabled);
*/
static u64 acpi_lapic_addr __initdata;
+/*
On Wed, 4 Dec 2013 10:35:54 -0800
Greg KH gre...@linuxfoundation.org wrote:
On Wed, Dec 04, 2013 at 06:09:41PM +, Serban Constantinescu wrote:
+#define size_helper(x) ({ \
+ size_t __size;
Not so much confused as simply merged. Input processing is inherently
single-threaded; it makes sense to rely on that at the highest level
possible.
I would disagree entirely. You want to minimise the areas affected by a
given lock. You also want to lock data not code. Correctness comes before
None of this (the patch series or the original code) is mine. My
Sorry mistraced the attribution sequence
question was more of a general one on designing ioctls, as well as
concerns with changing the existing 32-bit api.
I think in general my advice would be:
If its already been screwed up
On Thu, 5 Dec 2013 11:48:08 +0100
Pavel Machek pa...@ucw.cz wrote:
On Mon 2013-12-02 20:18:52, Matthew Garrett wrote:
The kernel as a number of cases of gendered language. The majority of these
refer to objects that don't have gender in English, and so I've replaced
them with it and its.
On Thu, 13 Mar 2014 20:33:06 +1100 (EST)
James Morris jmor...@namei.org wrote:
On Wed, 12 Mar 2014, Kees Cook wrote:
On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
matthew.garr...@nebula.com wrote:
On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
Ok, which tree should
On Thu, 13 Mar 2014 15:59:24 +
Matthew Garrett matthew.garr...@nebula.com wrote:
On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:
I'll take it, but there's unanswered review feedback (your response to the
first question), and Alan raised some doubts about the patches which I'm
On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
functionality - firmware loading and the fibmap ioctl are probably the
most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
userspace expectations, so we're kind of stuck there.
Actually I know how to
On Thu, 13 Mar 2014 21:30:48 +
Matthew Garrett matthew.garr...@nebula.com wrote:
On Thu, 2014-03-13 at 21:24 +, One Thousand Gnomes wrote:
If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
trivially and in a fashion well known and documented.
How?
You
Creating yet more kernel threads to solve this problem is a bit sad.
Is there no way in which we can borrow one of the existing threads?
schedule_work()
Surely that's all we need, if we get bunged up for a bit then it ends up
on a work queue item and everyone with a billion disks and a 9600
@@ -2325,10 +2323,19 @@ serial8250_do_set_termios(struct uart_port *port,
struct ktermios *termios,
if ((baud 2400 !up-dma) || fifo_bug) {
fcr = ~UART_FCR_TRIGGER_MASK;
fcr |= UART_FCR_TRIGGER_1;
+ /* Don't use
Have you actually looked at these patches? I've looked at every case of
RAWIO in the kernel. For cases that are hardware specific and tied to
fairly old hardware, I've ignored them. For cases which provide an
Yes I have - and it's not exactly localised: it modifies stuff all over
the tree when
The command line problem here is a total red herring. If you've got a
measured kernel, you have a measured command line. (If not, you don't
That would be the sensible approach, but it has some quite drastic
ramifications.
have a measured kernel.) Dealing with the command line has nothing to
But you keep talking about MSRs despite there being a patch that limits
access to MSRs. If you have specific examples of privilege escalations
that are possible even with these patches then please, mention them.
I mentioned MSRs once, and then you kept going on about it.
Your patches are all
I have a set of patches that appear acceptable to the security
maintainer. I've rewritten them multiple times in response to various
levels of bikeshedding. They solve a real problem and are being shipped
by multiple distributions.
And ? I've seen some of the other extra stuff distributions
On Fri, 14 Mar 2014 19:24:55 +
Matthew Garrett matthew.garr...@nebula.com wrote:
On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
The fact that you keep saying measured really does make me suspect that
you misunderstand the problem. There's no measurement involved, there's
On Fri, 14 Mar 2014 21:56:33 +
Matthew Garrett matthew.garr...@nebula.com wrote:
On Fri, 2014-03-14 at 21:48 +, One Thousand Gnomes wrote:
In your particularly implementation maybe you've got a weak setup where
you don't measure down to your initrd. That's a *flaw* in your
On Fri, 14 Mar 2014 22:15:45 +
Matthew Garrett matthew.garr...@nebula.com wrote:
On Fri, 2014-03-14 at 22:08 +, One Thousand Gnomes wrote:
On Fri, 14 Mar 2014 21:56:33 +
Matthew Garrett matthew.garr...@nebula.com wrote:
Signed userspace is not a requirement, and therefore any
So as far as the narrow question of whether we should accept these
patches, I think it's a good thing. Personally, I'm always going to
be disabling UEFI secure boot (even if it doesn't brick my laptop),
because for me, the security guarantees it provides isn't worth it.
But there will be
Root cause time: it's wrong for the oom-killer to use SIGKILL. In fact
It has to use SIGKILL anything else might be caught and grow the user
stack a page..
it's basically always wrong to send signals from in-kernel. Signals
are a userspace IPC mechanism and using them in-kernel a) makes it
Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.
[1] https://lkml.org/lkml/2014/2/20/434
Reported-by: Beat Bolli
BUG() normally causes a fault and we print helpful messages before killing
the task, and gcc knows we never continue because of the
__builtin_unreachable() annotation.
If BUG() is defined as 'do { } while (0)' in the example above, we get
a warning because the function may end without
On Sat, 22 Feb 2014 17:02:32 -0800
David E. Box david.e@linux.intel.com wrote:
From: David E. Box david.e@linux.intel.com
Add iosf_mbi_available function for loadable modules.
Add dummy functions to prevent symbol lookup errors on loadable modules.
Clarify that the write opcode is
This is a complete pointless test. Use a bog standard 8250 UART on the
PC and connect a microcontroller on the other end which serves you an
continous stream of data at 115200 Baud.
There is no way you can keep up with that without the low latency
option neither on old and nor on new
On Mon, 24 Feb 2014 05:21:43 -0800
H. Peter Anvin h...@zytor.com wrote:
On 02/24/2014 05:19 AM, One Thousand Gnomes wrote:
Other than _available I would have expected all the others to resolve to
returning an error or doing a WARN() in the not compiled in case.
WARN() or BUG()?
WARN
On Tue, 25 Feb 2014 02:45:57 -0800
H. Peter Anvin h...@zytor.com wrote:
On 02/24/2014 10:01 PM, Chris Bainbridge wrote:
Pentium M is PAE capable but does not indicate so in the CPUID response.
This is an issue now that some distributions are no longer shipping
non-PAE kernels (those
On Mon, 24 Feb 2014 06:26:52 -0800
Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
On Mon, Feb 24, 2014 at 03:03:25PM +0100, Michal Simek wrote:
BTW: Isn't this a good topic for kernel-summit? :-)
No, lawyers don't go to the summit, developers do.
More of a topic for the LF.
kernel was trusted - untrusted userspace could have set it on an untrusted
kernel, but by the same metric an untrusted kernel could just set it itself.
If people object to this name then I swear to god that I will open a poll
on Phoronix to decide the next attempt and you will like that
On Wed, 26 Feb 2014 15:11:13 -0500
Matthew Garrett matthew.garr...@nebula.com wrote:
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that the kernel prevent userspace from inserting untrusted
On Wed, 26 Feb 2014 12:09:27 -0700
Bjorn Helgaas bhelg...@google.com wrote:
Convert i2o_res_alloc() to use pci_bus_alloc_resource() rather than
pci_find_parent_resource() and allocate_resource(). We don't have a
resource to start with, so pci_find_parent_resource() can't do anything
useful:
I'm glad to hear that the Bluetooth uart interface is getting
some use; that means someone will soon be fixing the hard lockup
in hci_uart_tx_wakeup() reported here:
I'm not very familiar with the BT devices on our platforms, but most
of them are not using the in-kernel BT driver, some
On Sat, 01 Mar 2014 21:12:25 +
disbandtechc...@tfwno.gf wrote:
FOUR people made a decision that would once have required
thousands of votes. FOUR votes overrideds the decision
debian took before the tech-ctte dictatorship to standardize
on system V init rather than bsd style init scripts
On Fri, 28 Feb 2014 18:18:38 -0500
Santosh Shilimkar santosh.shilim...@ti.com wrote:
Based on earlier thread https://lkml.org/lkml/2013/10/7/662; and
further discussion at Kernel Summit'2013, it was agreed to create
'driver/soc' for drivers which are quite SOC specific.
Lets take the
On Mon, 03 Mar 2014 15:21:40 +0800
Li, Aubrey aubrey...@linux.intel.com wrote:
On 2014/3/1 10:40, David E. Box wrote:
From: David E. Box david.e@linux.intel.com
Some loadable modules only need IOSF access on the platforms where it
exists.
Provide dummy functions to allow these
We routinely expect 2 to 3 u-s jitters on an Atom board running a 32 bit,
RTAI enhanced build of what is by now a 5 year old kernel. This is
extremely board sensitive, and that same kernel running on this 4 core
phenom, cannot stay inside of 40 u-s. A case of more horsepower not being
a
On Tue, 4 Mar 2014 09:17:26 -0800
Soren Brinkmann soren.brinkm...@xilinx.com wrote:
The UART controller in Zynq is Cadence IP. Rename the driver
accordingly.
Furthermore, this affects the DT bindings:
- the compatibility string changes to 'cdns,uart-r1p8'
- clock inputs are named
Obvious bug
| Usage model is a thread mmaps this file during initialization. It then
| writes a 1 to the mmap'd file after it grabs the lock in its critical
| section where it wants immunity from pre-emption.
You need to write it first or you can be pre-empted taking the lock
before asking for
On Fri, 7 Mar 2014 22:00:51 +0100
Jean Delvare jdelv...@suse.de wrote:
As far as I know, the CS5535 and CS5536 chipsets are companions of the
Geode series of processors, which are 32-bit only. So the CS5535
drivers are not needed on x86-64, except for build testing purpose.
This aligns the
On Fri, 7 Mar 2014 11:13:27 -0800
Soren Brinkmann soren.brinkm...@xilinx.com wrote:
Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
drivers/tty/serial/xilinx_uartps.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
On Fri, 7 Mar 2014 11:13:29 -0800
Soren Brinkmann soren.brinkm...@xilinx.com wrote:
Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
---
I'm not sure about this change. Is this acceptable or already too much?
I think the name is used for some sysfs entries.
Its probably not a good
On Fri, 7 Mar 2014 11:13:31 -0800
Soren Brinkmann soren.brinkm...@xilinx.com wrote:
Rename the config symbols for the Cadence UART to reflect the driver
rebranding:
SERIAL_XILINX_PS_UART(_CONSOLE) - SERIAL_CADENCE_UART(_CONSOLE)
This breaks all those setups people have with pre-packed
On Thu, 6 Mar 2014 18:23:39 +0100
Andrew Lunn and...@lunn.ch wrote:
Can't we fix this so the probe order doesn't affect the name?
Is that sane?
You are not supposed to trust the device name, since probing can
happen in parallel, on different buses. udev should have rules to name
the
- The renderer supports *any* RGB target, from 8bit to 32bit with
big-endian and little-endian support. The related pixel-renderer will
probably never win a beauty-contest, but it works.. Again, who cares
for debug-log rendering speed?
Debug log writing performance is extremely
On Fri, 7 Mar 2014 15:08:00 -0800
Sören Brinkmann soren.brinkm...@xilinx.com wrote:
On Fri, 2014-03-07 at 09:28PM +, One Thousand Gnomes wrote:
On Fri, 7 Mar 2014 11:13:27 -0800
Soren Brinkmann soren.brinkm...@xilinx.com wrote:
Signed-off-by: Soren Brinkmann soren.brinkm
+#define DRV_NAME sc16is7xx
+#define DRV_VERSION 0.4
+#define SC16IS7XX_MAJOR 204
+#define SC16IS7XX_MINOR 8
Use dynamic minors for any new device
+static inline u8 sc16is7xx_read(struct uart_port *port, u8 reg)
I wouldn't inline this - the compiler will figure it out for
On Mon, 10 Mar 2014 07:50:12 -0400 (EDT)
Jon Ringle j...@ringle.org wrote:
On Mon, 10 Mar 2014, Alexander Shiyan wrote:
Понедельник, 10 марта 2014, 2:26 -04:00 от j...@ringle.org:
From: Jon Ringle jrin...@gridpoint.com
...
+config SERIAL_SC16IS7XX
+ tristate SC16IS7xx RS485
On Mon, 10 Mar 2014 01:53:33 +0100
Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote:
On 03/10/2014 01:41 AM, David Miller wrote:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Date: Mon, 10 Mar 2014 01:37:32 +0100
The mechanism is manual, no automatic way to
No one unbinds serial drivers using serial_core, as all these drivers are
for fixed hardware?
Yep, never tested until now :)
Do you need this to work?
Hot-pluggable usb-serial doesn't use serial_core.
I guess none of the 8250 PCI adapters are hot-pluggable...
pcmcia 8250 certainly
On Tue, 11 Mar 2014 14:49:25 +0200
Tomas Winkler tomas.wink...@intel.com wrote:
From: Alexander Usyskin alexander.usys...@intel.com
Consistently display error on possible copy_from/to_user failures
and replace dev_dbg with dev_err
NAK
This allows users to flood the logs by deliberately
(Although honestly, that whole thing is so long ago that my dim
memory is very suspect, and it's possible the workaround actually
came independently of that from Alan Cox. This all happened in
v2.4.13-rc2 - late 2001 - and the PPro workaround came in together
with the X86 OOSTORE code, which
So 32-bit x86 is dead, dead, dead. There's absolutely no future to it.
We're not adding new stuff to future-proof it.
I think you underestimate how long it'll be present given the advantages
of 32bit in certain situations like very very small devices. Intel is
still releasing new 32bit
On Sun, 12 Jan 2014 20:33:03 +0700
Linus Torvalds torva...@linux-foundation.org wrote:
Another week, another RC. And things look fine.
It seems to hate Baytrail/T
My ASUS T100TA has gone from 3.11 'needs video=VGA-1:blah' to get the mode
right but otherwise running nicely and playing 3D games
Maybe we should unset the low_latency flag as soon as DMA fails? There
are two flags, one is state-uart_port-flags and the other is
port-low_latency. I guess we need to unset both.
Well low latency and DMA are pretty much exclusive in the real world so
probably DMA ports shouldn't allow
On Tue, 14 Jan 2014 16:23:23 +0800
Dave Young dyo...@redhat.com wrote:
In kdump kernel watchdog could interrupt vmcore capturing because we
have no way to disable/stop it while crashing happens.
Lots of watchdogs cannot be stopped.
Add a module parameter stop_before_register so watchdog can
According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt
trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.
This patch makes a 16550A
And maybe make a statement that linux is NOT systemd, there is no
new linux software stack that pottering and friends keep insisting on.
The largest Linux user is Android, which I don't think uses systemd. The
kernel does not care. You can use emacs as your init for all the kernel
cares and
How? What two different busses will see this same device? The amba bus
code should prevent that from happening, right? If not, there's bigger
problems in that bus code :)
Where is that requirement documented? It isn't documented. No one
implements any kind of locking at the bus
#define TIOCSFIFORTRIG_IOW('T', 0x41, unsigned char)
Also, why pass a pointer to a variable, and not just the value itself?
Ah, it's no big reason.
It will pass just the value itself in V2.
We don't need ioctls here - we have a sysfs interface we can expand to do
this. We also need
And an even simpler broad brush approach will also work I think (untested)
The zero crap approach
commit c5cd0be0576ba9059799ef5383402ff6ffc212a3
Author: Alan gno...@lxorguk.ukuu.org.uk
Date: Mon Feb 17 15:52:21 2014 +
tty: Allow serial port allocations to be fully dynamic
v2: Resend due to mail format issues. More Thunderbird settings applied.
I know very little of this code, and I'm not sure this is a good solution,
so here's some background:
I wouldn't worry too much. I'm amazed the code even works these days.
It's incredibly bitrotted and doesn't use the
spin_lock's there. Maybe we can create WQ_HIGHPRI workqueue and schedule
flush_to_ldisc() work there. Or perhaps users that need to low latency,
should switch to thread irq and prioritize serial irq to meat
retirements. Anyway setserial low_latency is now broken and all who use
this feature
1 - 100 of 1572 matches
Mail list logo
