> Maybe drivers/bus would be more appropriate though. Every platform
> handles platforms differently, and x86 seems to be the only one that
> likes the model of putting stuff under drivers/platform.
I'm fine with that and I agree - it is a bus.
> __devinit/__devexit are going away, so you can ski
On Thu, 10 Jan 2013 15:46:26 +0100
Florian Westphal wrote:
> Frank Lichtenheld discovered that openpty() doesn't work anymore when
> /dev/pts is not present.
>
> We bisected this down to
>
> commit bbb63c514a3464342967237a51a21ea8f61ab951
> Author: Wanlong Gao
> Subject: drivers:tty:fix up ENO
: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Ported to 3.4]
Signed-off-by: Tom Keel
[Ported to 3.7 and tided for checkpatch etc]
Signed-off-by: Alan Cox
---
drivers/mtd/devices/Kconfig |7
drivers/mtd/devices/Makefile|3
drivers/mtd
From: Arve Hjønnevåg
Gets the current time from the host. Alarms are not supported yet.
Signed-off-by: Mike A. Chan
Signed-off-by: Arve Hjønnevåg
[Ported to 3.4]
Signed-off-by: Tom Keel
[Cleaned up to use ioremap, types, unload etc]
Signed-off-by: Alan Cox
---
arch/x86/include/asm
ohui
Signed-off-by: Jiang, Yunhong
Signed-off-by: Nakajima, Jun
[Ported to 3.6]
Signed-off-by: Tom Keel
[Ported to 3.7, moved to platform/goldfish]
Signed-off-by: Alan Cox
---
drivers/platform/Kconfig |4
drivers/platform/goldfish/Kconfig |5
drivers/platform/
Yang
Signed-off-by: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[ported to 3.4]
Signed-off-by: Tom Keel
[ported to 3.7 and final tidy]
Signed-off-by: Alan Cox
---
drivers/power/Kconfig|8 +
drivers/power/Mak
From: Mike Lockwood
This driver handles the virtual MMC device present in the Goldfish emulator.
The patch folds together initial work from Mike Lockwood and patches by
San Mehat, Jun Nakajima and Tom Keel plus cleanups
by Alan Cox to get it all into 3.6 shape.
Signed-off-by: Mike A. Chan
: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[ported to 3.4]
Signed-off-by: Tom Keel
[cleaned up for style and 3.7, moved blank methods]
Signed-off-by: Alan Cox
---
drivers/video/Kconfig |9 +
drivers/video/Makefile |1
Mike A. Chan
[Tided up to work on x86]
Signed-off-by: Sheng Yang
Signed-off-by: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Ported to 3.4]
Signed-off-by: Tom Keel
[Cleaned up for 3.7 and submission]
Signed-off-by: Alan Cox
---
drivers/in
From: Arve Hjønnevåg
This provides a console driver for the Goldfish virtual platform. The original
is from Arve with changes from Jun Nakajima and Tom Keel. This has been then
been ported to the current kernel and to the tty port mechanism by Alan Cox.
In the process it gained proper POSIX
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Moved out of x86, cleaned up headers]
Signed-off-by: Alan Cox
---
drivers/platform/Makefile|1
drivers/platform/goldfish/Makefile |4 +
drivers/platform/goldfish/pdev_bus.c | 265
-by: Bruce Beare
[Ported to 3.7 and reorganised so that we can keep most of the code
shared properly]
Signed-off-by: Alan Cox
---
arch/x86/Kconfig| 12
arch/x86/include/asm/goldfish.h | 33 +
2 files changed, 45 insertions
And added the pipe driver
---
Arve Hjønnevåg (4):
goldfish: tty driver
goldfish: framebuffer
goldfish: real time clock
goldfish: NAND flash driver
Brian Swetland (1):
goldfish: virtual input event driver
David 'Digit' Turner (1):
goldfish: add QEMU pipe drive
> Yes. The case I tried was a large write (strace cat /etc/somefile >
> /dev/ttyDA2) and strace showed a single large write, but it got to the
> driver in chunks of a dozen or so characters. Is that expected to happen?
Yes it is - the tty mid layer code could do better on this but it's never
been
> So to add such an "I am crap" flag my idea would be to add an
> .fb_handle_damage to struct fb_ops and then call that (if exists)
> whenever something was changed.
I was thinking much higher level - ie at the printk kind of level
> My patch (for udlfb) follows as an reply to this message. If
> >> +static int put_data(void *arg)
> >> +{
> >> + struct dashbuf *dbuf;
> >> + int number_written;
> >> +
> >> + __set_current_state(TASK_RUNNING);
> >> + while (!kthread_should_stop()) {
> >> + /*
> >> + * Pick up all the output buffers and write them out.
> >> +
On Fri, 04 Jan 2013 13:50:37 +0100
Alexander Holler wrote:
> Am 28.12.2012 13:40, schrieb Borislav Petkov:
> > On Fri, Dec 28, 2012 at 07:50:27PM +0800, Shawn Guo wrote:
> >> +1
> >>
> >> http://thread.gmane.org/gmane.linux.kernel/1413953/focus=1415070
> >
> > Cool, works fine here too. Is Linus
> The only patch I could find [1] (mid Nov) looks like it needs another
> sites updating, since we now see an i915 vs efifb lock ordering issue
> [2].
>
> I can get some time next week to take a look if it helps.
That would be great. I've not got any EFI afflicted hardware and I'm
doing my best t
On Thu, 3 Jan 2013 20:56:30 +0800
Daniel J Blueman wrote:
> On 3.8-rc2 with lockdep enabled and dual-GPU setup (Macbook Pro
> Retina), I see two releated lock inversion issues with the EFI
> framebuffer, leading to possible deadlock: when X takes over from the
> EFI framebuffer [1] and when nouve
> Looks good, but I would prefer the layer to provide us with
> wake_up_if_active...
Seconded - this is a problem for the wake up logic in the RT tree. Why
would we ever do anything else ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On Wed, 19 Dec 2012 22:59:19 +0400
Ilya Zykov wrote:
> We should not write toward the closed pty.
> Now it happens, if one side close last file descriptor,
> and other side in this moment write to it.
> It also prevents scheduling unnecessary work.
>
> Signed-off-by: Ilya Zykov
> ---
> driver
> This would thwart all sorts of social and physical attacks on the device.
>
> Has something like this ever been attempted?
man cryptsetup
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
t; we have no tx_lock in gsm_send.
>
> This patch is to add tx_lock in gsm_send.
>
> Signed-off-by: xiaojin
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
On Thu, 20 Dec 2012 12:13:07 +
"Xiao, Jin" wrote:
> Alan,
>
> Thanks. But the comment makes me confused. As we see, gsm->output is called
> by gsm_data_kick too, and it's in the tx_lock...
That would be a bug too or I guess we could finally give in on trying to
keep tty write paths not us
On Thu, 20 Dec 2012 13:25:55 +0100
Borislav Petkov wrote:
> I'm getting this
>
> drivers/ata/libata-core.c: In function ‘ata_hpa_resize’:
> drivers/ata/libata-core.c:1397:3: warning: ‘native_sectors’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>
> for a couple of kerne
On Thu, 20 Dec 2012 08:38:40 +0800
Xiao Jin wrote:
> From: xiaojin
> Date: Wed, 19 Dec 2012 11:53:43 +0800
> Subject: [PATCH] n_gsm.c: add tx_lock in gsm_send
>
> All the call to gsm->output should be in the tx_lock,
> that could avoid potential race from MUX level. But
> we have no tx_lock in
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Moved out of x86, cleaned up headers]
Signed-off-by: Alan Cox
---
drivers/platform/Makefile|1
drivers/platform/goldfish/Makefile |4 +
drivers/platform/goldfish/pdev_bus.c | 265
-by: Bruce Beare
[Ported to 3.7 and reorganised so that we can keep most of the code
shared properly]
Signed-off-by: Alan Cox
---
arch/x86/Kconfig| 12
arch/x86/include/asm/goldfish.h | 33 +
2 files changed, 45 insertions
Add the base component of the Goldfish virtual android device on x86 systems.
These need to be merged first so the driver support can follow
---
Jun Nakajima (2):
goldfish: definitions for Goldfish on x86 platforms
goldfish: add the goldfish virtual bus
arch/x86/Kconfig
> diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
> index a82b399..1ce1362 100644
> --- a/drivers/tty/pty.c
> +++ b/drivers/tty/pty.c
> @@ -116,6 +116,8 @@ static int pty_space(struct tty_struct *to)
>
> static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)
> {
> +
On Tue, 18 Dec 2012 13:04:49 -0800
Kees Cook wrote:
> Some devices have configurable firmware locations. If these configuration
> mechanisms are exposed to unprivileged userspace, it may be possible to
> load firmware from an unexpected location. To minimize the risk of this,
> make sure the stri
led RTS and CTS flow control to reduce SW overhead.
>
> Add serial driver to use all above feature.
>
> Signed-off-by: Laxman Dewangan
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
> +
> +static void tegra_uart_copy_rx_to_tty(struct tegra_uart_port *tup, int count)
> +{
> + int copied;
> +
> + tup->uport.icount.rx += count;
> + dma_sync_single_for_cpu(tup->uport.dev, tup->rx_dma_buf_phys,
> + TEGRA_UART_RX_DMA_BUFFER_SIZE, DMA_FROM_DE
On Sat, 15 Dec 2012 00:54:48 +
Eric Wong wrote:
> Applications streaming large files may want to reduce disk spinups and
> I/O latency by performing large amounts of readahead up front
How does it compare benchmark wise with a user thread or using the
readahead() call ?
--
To unsubscribe fr
> We can make this feature (passing O_DENY* flags received from clients
> to filesystem) can be turned on/off on Samba/NFS server to let this
> particular use case work. In general, I think we really need to be
> sure that nobody has a read access for files that a Windows process
> opened with O_DE
On Fri, 14 Dec 2012 15:55:33 +0400
> Seems like this is different bugs, that was in "i7core_edac", this one in
> "edac_core"
Agreed
--
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 http://vger
On Fri, 14 Dec 2012 15:03:10 +0400
Konstantin Khlebnikov wrote:
> This patch fixes use-after-free and double-free bugs in edac_mc_sysfs_exit().
> mci_pdev has single reference and put_device() calls mc_attr_release() which
> calls kfree(), thus following device_del() works with already released m
On Fri, 14 Dec 2012 15:01:37 +0400
Konstantin Khlebnikov wrote:
> This patch uncomments ata timings for XFER_PIO_SLOW,
> otherwise ata_timing_find_mode() returns NULL and kernel crashes in
> pacpi_set_dmamode() after null-pointer dereference.
NAK please see the previous discussion of this and th
On Fri, 14 Dec 2012 03:01:24 +
"Fangxiaozhi (Franko)" wrote:
> Dear Alan:
>
> This prevents people getting access to the storage device if they want.
> In our device, after its switching, it will keep the cdrom port
> together with other ports (such as modem port). So you ca
On Wed, 12 Dec 2012 18:20:33 +0800
fangxiaozhi 00110321 wrote:
> From: fangxiaozhi
>
> 1. To optimize the match rules for the Huawei USB storage devices. Avoid to
> load USB storage driver for modem interface with Huawei devices.
> 2. Add to support new switch command for new Huawei USB dongle
> The problem comes when you end up trying to deal with stuff which
> uses ioread{8,16} on ioport_map() cookies where it's assumed that
> adding N to the cookie is the same as adding N to the port address.
It's a cookie - this isn't a problem, you can support it via the mapping
approah. Whether yo
> with it. It's very simple. The IO port space is for ISA/PCMCIA and
> PCI IO port regions. It is nothing more than that.
And on a lot of devices the LPC bus.
> Plus, if you _have_ IO space support, you must have some MMIO region for
> them to target - doing what many platforms have done to da
> Could you enlighten my very naive understanding of things about PCI/ISA
> IO space? On x86, I seem to understand this is the separate address
> space accessed by the special in/out CPU instructions. Are there ARM
> platforms with the same sort of things?
An x86 processor has two address spaces
> Correct. If HAS_IOPORT is not selected then we are potentially missing
> the dependent functions (because the platform has no IOPORT support) _or_
> it does have ISA/PCI IO spaces _but_ they're not mappable via the
> ioport_map() mechanism due to some non-linearity involved in the
> translation.
> @@ -2068,13 +2097,18 @@ int vt_do_kdgkbmode(int console)
> return K_MEDIUMRAW;
> case VC_UNICODE:
> return K_UNICODE;
> - case VC_OFF:
> - return K_OFF;
Trying to work out why this change is made ?
--
To unsubscribe from this list: send the line
On Tue, 11 Dec 2012 01:01:29 +0100
Alexander Holler wrote:
> Am 10.12.2012 23:36, schrieb Lars-Peter Clausen:
> > Well, I've been exaggerating a bit, you can call it multiple times, but you
>
> Thanks a lot for the explanation(s).
>
> +error_free_drvdata:
> +platform_set_drvdata(p
> > You see, there is no serial8250 informations.
> >
> > Can anyone here please tell me how this can happen? Does it mean the
> > serial8250 driver don't populate or register in the /proc/iomem?
>
> Could someone help me? Thanks!
I think you are in the wrong place - the kernel newbies list may
On Sun, 09 Dec 2012 01:58:19 -0800
anish kumar wrote:
> On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
> > > I could imagine declaring the activity request buttons to be "input", but
> > > for
> > > presence detects it is a bit far fetched
On Sat, 8 Dec 2012 01:41:23 +
Cong Ding wrote:
> remove trailing blank spaces in tty/hvc by shell command:
> sed 's/\s\+$//g' -i
>
> I have manually reviewed that everything is correct.
>
> Signed-off-by: Cong Ding
Both acked-by: Alan Cox
Thanks
Alan
--
T
On Sat, 8 Dec 2012 11:52:34 +0100
Borislav Petkov wrote:
> On Sat, Dec 08, 2012 at 08:36:34AM +0100, Andreas Mohr wrote:
> > And that demand actually applies to both the '@' change (questionable)
> > and the much less disputed (obviously correct) wrong conditional
> > fixup, since both introduce
> Which kind of configuration is right for ARM? I think the
> 8250_exar_st16c554.c is for ISA bus board and hence is not suit to me,
> but I am not sure my understanding is right. Please give me some
> backgroud information on this field.
You are the one who should have the information for your b
> The problem is the possibility of denial-of-service attacks here. We
> can try to prevent them by:
> 1) specifying an extra security bit on the file that indicates that
> share flags are accepted (like we have for mandatory locks now) and
> setting it for neccessary files only, or
> 2) adding
> In the extreme case, define blocks with only a single GPIO in each of
> them, and the interface should still be faster than the sysfs one. Each
> block is a separate device node with separate permissions.
Ok, so it degenerates to the same case if needed. It's not ideal but I
have no suggestions
> Because I need to use IO functions which will behave
> on arm as little endian and on powerpc as big endian
> and on microblaze depends on endian setting.
> I haven't found any IO function which I could use by 3 architectures
> without using preprocessor macros or runtime detection
Its a rather
On Fri, 07 Dec 2012 13:16:33 +0100
Roland Stigge wrote:
> On 12/07/2012 01:06 PM, Roland Stigge wrote:
> > On 12/07/2012 11:36 AM, Alan Cox wrote:
> >>> * Device interface for userland access (alternative to sysfs)
> >>
> >> Currently we can set differ
> I could imagine declaring the activity request buttons to be "input", but for
> presence detects it is a bit far fetched and would add too much complexity.
Android tries to address this with its switch class driver, but I'm not
sure its actually got anything over making them input devices.
Alan
> I suspect that WINE would have the same need
Tricky - Wine needs to enforce this behaviour solely between Wine and
the file server, Trying to muck up non emulated local behaviour would be
a bad mistake.
One way perhaps to look at this is you want some tasks to be able to *opt
in* to this behavi
> I'm not sure if I understand what you mean here.
>
> We put them in hierarchy if the parent ACPI node has also a physical device
> bound to it (like PCIe root port).
Ok
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
On Fri, 7 Dec 2012 12:08:02 +0200
Mika Westerberg wrote:
> All devices behind Haswell LPSS (Low Power Subsystem) should be represented
> as platform devices
What about the bus heirarchy ? What about making sure they appear in the
PCI resource heirarchy so we don't mash them up if we reassign o
> * Device interface for userland access (alternative to sysfs)
Currently we can set different permissions on different GPIO lines. Your
driver change drives a truck through this facility.
I'm not sure there is an elegant way to snoop on the permissions set
on the sysfs gpio nodes and the driver
> The UART controller is EXAR ST16C554D. It claims as a 16550
> compatible controller. Each ST16C554D module contains 4 UART, each of
> them can be selected via two chip select pad. I think the board
> hardware, via a CPLD, make the chip selection transparent to the CPU, so
> by a 5-bit address, C
> I would suggest to write a series of scripts. And then announce a date
> (preferably some holiday like Xmas) to run these scripts. The announce is to
> avoid conflicts with other developers. It will save both developers' and
> subsystem maintains' time, do you agree?
And if any of them are wrong
On Thu, 6 Dec 2012 22:26:28 +0400
Pavel Shilovsky wrote:
> Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this
> change can benefit cifs and nfs modules. While this change is ok for network
> filesystems, itsn't not targeted for local filesystems due security problems
>
> The last patch you sent wasn't ignored. You got this comment from Bjorn:
>
> http://thread.gmane.org/gmane.linux.acpi.devel/56753
Ok that one never made it to me for some reason.
> that you didn't respond to, so I'm still unsure what to do with that patch.
I think Bjorn is correct.
Alan
--
On Wed, 5 Dec 2012 22:12:45 +0100
Borislav Petkov wrote:
> On Thu, Dec 06, 2012 at 07:57:21AM +1100, Stephen Rothwell wrote:
> > On Wed, 5 Dec 2012 15:47:49 +0000 Alan Cox wrote:
> > > And yes btw we should turn this option on in -next, and get these sort of
> > >
> While I appreciate your confidence, I don't notice quite a few new
> warnings (because there are so many of them already :-(). Is there some
> reason to not turn this on in our "normal" builds? Does it produce many
> false positives? What compiler version is required?
I've not seen any false
> +/* One struct dashtty exists per open channel. */
> +struct dashtty {
> + struct tty_struct *tty;
> + struct tty_port *port;
> +};
We have tty->port as of 3.7 so you shouldn't need this any more
> +
> +static struct tty_port dashtty_ports[NUM_TTY_CHANNELS];
> +
> +struct dashbuf {
>
On Wed, 05 Dec 2012 17:15:40 +0100
Sebastian Andrzej Siewior wrote:
> On 12/03/2012 06:41 PM, Peter Hurley wrote:
> > The lock logic for tty_set_ldisc() is wrong. Despite existing code in
> > tty_set_ldisc() and tty_ldisc_hangup(), the ldisc_mutex does **not**
> > (and should not) play a role in
> Hillarious!
>
> Andrew, would you please pick up Alan's patch? It clearly fixes an
> ancient bug in the pnpacpi code.
And yes btw we should turn this option on in -next, and get these sort of
things out of the tree for good. More importantly it'll mean anyone
adding another one gets a whine on
On Wed, 5 Dec 2012 15:29:35 +0100
Borislav Petkov wrote:
> On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> > Hi,
> >
> > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> > drivers/pnp/pnpacpi/core.c:65:2: warning: logical 'or' of collectively
> > exhaustive tests is alway
On Tue, 4 Dec 2012 16:02:17 +
"Winkler, Tomas" wrote:
> > > > As to overhead. I'd love to see a measurement that can detect
> > > > the difference. Do you have a benchmark that shows it ?
> > >
> > > Don't have any numbers but it seems reasonable to me.
> >
> > Processors are pretty good at
> > so you need to tweak the map/unmap if you do this.
> >
> > As to overhead. I'd love to see a measurement that can detect the
> > difference. Do you have a benchmark that shows it ?
>
> Don't have any numbers but it seems reasonable to me.
Processors are pretty good at prediction these days.
On Tue, 4 Dec 2012 16:04:36 +0200
Tomas Winkler wrote:
> on intel registers are alwasy memory mapped so drop
> the overhead of iowrite32 and ioread32
>
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/mei_dev.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff -
> I assume you mean somewhere other than ml archives:
> https://lkml.org/lkml/2012/12/1/57
Putting in the commit message would be idea given how short it is.
>
> Setting up a mini-testsuite is good idea. As I noted in that email
> though, that test jig is a derivative work that I'd want a ok fro
ng data to ldisc.
>
> Also revert:
> commit c56a00a165712fd73081f40044b1e64407bb1875
> tty: hold lock across tty buffer finding and buffer filling
> In order to delete the unneeded locks any more.
>
> Signed-off-by: Ilya Zykov
Acked-by: Alan Cox
--
To unsubscribe from this list
On Tue, 4 Dec 2012 02:07:36 -0500
Peter Hurley wrote:
> This patch series addresses the causes of flush_to_ldisc accessing
> the tty after freeing.
Looks good to me. Would be nice to keep a copy of the test that shows
it up in the comments of the patches somewhere.
--
To unsubscribe from this l
> Main idea here - we never flash last (struct tty_buffer) in the
> active buffer. Only data for ldisc. (tty->buf.head->read =
> tty->buf.head->commit). At that moment driver can collect(write) data
> in buffer without conflict.
This one I agree with (sorry it took a while to get to, I wanted to
On Tue, 4 Dec 2012 06:17:25 + (UTC)
Woody Wu wrote:
> Hi, list
>
> I am not sure this has something with kernel. But the system I just
> generated cannot be reached from ping. It can ping outside, but if I
> ping it from outside, I just get "Destination Host Unreachable".
>
> I think ther
On 3 Dec 2012 16:19:11 -0500
"George Spelvin" wrote:
> (Not sure who owns this; Cc: to the last few people to touch
> drivers/tty/vt/keyboard.c.)
linux-input is probably the best place to discuss this
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Ported to 3.4]
Signed-off-by: Tom Keel
[Ported to 3.7 and tided for checkpatch etc]
Signed-off-by: Alan Cox
---
drivers/mtd/devices/Kconfig |7
drivers/mtd/devices/Makefile|3
drivers/mtd
From: Arve Hjønnevåg
Gets the current time from the host. Alarms are not supported yet.
Signed-off-by: Mike A. Chan
Signed-off-by: Arve Hjønnevåg
[Ported to 3.4]
Signed-off-by: Tom Keel
[Cleaned up to use ioremap, types, unload etc]
Signed-off-by: Alan Cox
---
arch/x86/include/asm
Yang
Signed-off-by: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[ported to 3.4]
Signed-off-by: Tom Keel
[ported to 3.7 and final tidy]
Signed-off-by: Alan Cox
---
drivers/power/Kconfig|8 +
drivers/power/Mak
From: Mike Lockwood
This driver handles the virtual MMC device present in the Goldfish emulator.
The patch folds together initial work from Mike Lockwood and patches by
San Mehat, Jun Nakajima and Tom Keel plus cleanups
by Alan Cox to get it all into 3.6 shape.
Signed-off-by: Mike A. Chan
Mike A. Chan
[Tided up to work on x86]
Signed-off-by: Sheng Yang
Signed-off-by: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Ported to 3.4]
Signed-off-by: Tom Keel
[Cleaned up for 3.7 and submission]
Signed-off-by: Alan Cox
---
drivers/in
: Yunhong Jiang
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[ported to 3.4]
Signed-off-by: Tom Keel
[cleaned up for style and 3.7, moved blank methods]
Signed-off-by: Alan Cox
---
drivers/video/Kconfig |9 +
drivers/video/Makefile |1
From: Arve Hjønnevåg
This provides a console driver for the Goldfish virtual platform. The original
is from Arve with changes from Jun Nakajima and Tom Keel. This has been then
been ported to the current kernel and to the tty port mechanism by Alan Cox.
In the process it gained proper POSIX
Signed-off-by: Xiaohui Xin
Signed-off-by: Jun Nakajima
Signed-off-by: Bruce Beare
[Moved out of x86, cleaned up headers]
Signed-off-by: Alan Cox
---
drivers/platform/Makefile|1
drivers/platform/goldfish/Makefile |4 +
drivers/platform/goldfish/pdev_bus.c | 267
-by: Bruce Beare
[Ported to 3.7 and reorganised so that we can keep most of the code
shared properly]
Signed-off-by: Alan Cox
---
arch/x86/Kconfig| 12
arch/x86/include/asm/goldfish.h | 36
2 files changed, 48 insertions
This is a port and clean up of the core platform and driver code for
the Goldfish AVD (Android Virtual Device).
With these patches applied you can boot Debian on Goldfish for minimal testing
purposes. It won't boot Android as there are other drivers needed, some of
which still need out of tree And
On Mon, 3 Dec 2012 13:17:57 +0200
Heikki Krogerus wrote:
> This needs to be done in order to later access the
> Designware specific registers.
>
> Signed-off-by: Heikki Krogerus
Series Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Sun, 2 Dec 2012 10:11:58 -0600
Paul Fulghum wrote:
> True, in this mode line disciplines other than N_HDLC would not be functional
> and N_HDLC ignores the flag buffer.
> This change won’t make other line disciplines useful, it will just prevent
> the case of a mistakenly selected line disci
> + * If a different line discipline is selected
> by mistake it
> + * will have valid memory for both arguments.
> + */
> + ldisc_receive_buf(tty, buf->data, buf->data,
> framesize)
> Sorry, In you reply not all patch.
> Main idea here - we never flash last (struct tty_buffer) in the
> active buffer. Only data for ldisc. (tty->buf.head->read =
> tty->buf.head->commit). At that moment driver can collect(write) data
> in buffer without conflict.
Ah.. now I understand. Yes that
> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> index 6c9b7cd..4f02f9c 100644
> --- a/drivers/tty/tty_buffer.c
> +++ b/drivers/tty/tty_buffer.c
> @@ -114,11 +114,14 @@ static void __tty_buffer_flush(struct tty_struct *tty)
> {
> struct tty_buffer *thead;
>
> - whil
On Thu, 29 Nov 2012 13:07:28 +0800
Chen Gang wrote:
> Hello Greg Kroah-Hartman:
>
> for MAX_ASYNC_BUFFER_SIZE:
> it is defined as 4096;
> but for the max buffer size which it processes, is 65535.
> so suggest to #define MAX_ASYNC_BUFFER_SIZE 0x1 (better than 0x)
I don't see the n
> All I know is that it is present and its size is known. If I have a way of
> knowing
> what range of mmio memory is unclaimed; I could grab that perhaps using
> the request_mem_region() call, I know the size that is reserved for this
> device.
> So, is there a way to query the system for the fi
On Wed, 28 Nov 2012 11:50:28 -0800
"H. Peter Anvin" wrote:
> From: "H. Peter Anvin"
>
> All 486+ CPUs support WP in supervisor mode, so remove the fallback
> 386 support code.
This breaks the Nx586 support. Do we care: I doubt it 8)
--
To unsubscribe from this list: send the line "unsubscribe
> + if (!reg || (reg & 0xff) != '*')
> + return;
> +
That looks bogus. If reg == 0 then reg & 0xFF != '*'
So why the double test ?
--
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
On Wed, 28 Nov 2012 02:55:30 +
"Yangbin (Robin)" wrote:
> Hi all:
>
> I write a kernel module which make a dir and create a file in proc file
> system.
> I use proc_mkdir() and create_proc_entry() in init and use
> remove_proc_entry() in exit.
> Now I got a problem during my test:
>
> No, if only you will accept:
> [PATCH]tty: Incorrect use tty_ldisc_flush() in TTY drivers.
>
> It can be done another way, simple revert:
> 'tty: fix "IRQ45: nobody cared"'
> commit 7b292b4bf9a9d6098440d85616d6ca4c608b8304
NAK that revert - that swaps a minor glitch you've discovered that does
501 - 600 of 5738 matches
Mail list logo
