* Re: linux-next: Tree for Aug 24
From: Arnaud Lacombe @ 2011-08-25 4:30 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML
In-Reply-To: <CACqU3MXy6vyeLeTbZ+8OXfMowO2j0avSy6XgYJQ-C9N9YyU3GQ@mail.gmail.com>
Hi,
On Wed, Aug 24, 2011 at 9:38 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Wed, Aug 24, 2011 at 2:04 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>>
>> Changes since 20110823:
>>
>> New tree: kvmtool
>>
>> The security tree lost its build failure.
>>
>> The ptrace tree gained a build failure (yeaterday) for which I have
>> reveretd a commit.
>>
>> The tty tree gained a build failure so I used the version from
>> next-20110823.
>>
>> The staging tree gained a conflict against the fbdev tree and a build
>> failure for which I reverted a commit.
>>
>> The moduleh tree gained a conflict against the staging tree.
>>
> Quickly testing a new configuration blows up on the following:
>
> console [ttyS0] enabled
> Fast TSC calibration failed
> TSC: Unable to calibrate against PIT
> TSC: No reference (HPET/PMTIMER) available
> Marking TSC unstable due to could not calculate TSC khz
> Calibrating delay loop... 154.88 BogoMIPS (lpj=77440)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Intel QEMU Virtual CPU version 0.13.0 stepping 03
> BUG: unable to handle kernel paging request at 827bf688
> IP: [<c13945e2>] apply_alternatives+0xc3/0x18a
> *pde = 00000000
> Oops: 0000 [#1] DEBUG_PAGEALLOC
>
> Pid: 0, comm: swapper Not tainted 3.1.0-rc3-next-20110824+ #5 Bochs Bochs
> EIP: 0060:[<c13945e2>] EFLAGS: 00000286 CPU: 0
> EIP is at apply_alternatives+0xc3/0x18a
> EAX: ffffffff EBX: c13df690 ECX: 00000005 EDX: 827bf688
> ESI: 827bf688 EDI: c1367e9e EBP: c1367fa8 ESP: c1367e70
> DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
> Process swapper (pid: 0, ti=c1366000 task=c136c340 task.ti=c1366000)
> Stack:
> 00000002 c137b700 c1142ac0 00000dc6 c1367e9e 8268a422 00000005 827bf688
> c13dffd8 c1367e05 05000086 f6890046 00f69000 c1367eb0 00000086 00000000
> 00000046 c1367ec0 00000046 00000000 c1367edc c101f3cc 00000dd3 00000000
> Call Trace:
> [<c1142ac0>] ? serial8250_start_tx+0xe0/0xe0
> [<c101f3cc>] ? console_unlock+0x10c/0x150
> [<c12ab669>] ? common_interrupt+0x29/0x30
> [<c1023c64>] ? irq_exit+0x54/0x90
> [<c1003a93>] ? do_IRQ+0x43/0xa0
> [<c12ab669>] ? common_interrupt+0x29/0x30
> [<c13954a8>] ? check_fpu+0xae/0xdc
> [<c13946c0>] alternative_instructions+0x17/0x32
> [<c1395567>] check_bugs+0x91/0x93
> [<c138f6bb>] start_kernel+0x28e/0x299
> [<c138f1b7>] ? loglevel+0x1a/0x1a
> [<c138f0b3>] i386_start_kernel+0xb3/0xbb
> Code: ec fe ff ff 8d 0c 0b 89 8d dc fe ff ff 8d 54 13 04 8b bd d8 fe
> ff ff 89 95 e4 fe ff ff 89 b5 e0 fe ff ff 8b 8d e0 fe ff ff 89 d6 <f3>
> a4 80 bd f6 fe ff ff e8 75 17 80 bd ec fe ff ff 05 75 0e 89
> EIP: [<c13945e2>] apply_alternatives+0xc3/0x18a SS:ESP 0068:c1367e70
> CR2: 00000000827bf688
> ---[ end trace 4eaa2a86a8e2da22 ]---
>
> .config attached. I'll try to bisect it.
>
ok, this is a regression in 3.1, continuing bisection...
- Arnaud
^ permalink raw reply
* linux-next: manual merge of the usb tree with the usb.current tree
From: Stephen Rothwell @ 2011-08-25 4:52 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Kuninori Morimoto, Sarah Sharp
Hi Greg,
Today's linux-next merge of the usb tree got a conflict in
drivers/usb/host/xhci-ring.c between commit 48df4a6fd8c4 ("xhci: Handle
zero-length isochronous packets") from the usb.current tree and commit
29cc88979a88 ("USB: use usb_endpoint_maxp() instead of le16_to_cpu()")
from the usb tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/usb/host/xhci-ring.c
index 54139a2,bf0b52c..0000000
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@@ -3249,11 -3237,9 +3249,11 @@@ static int xhci_queue_isoc_tx(struct xh
addr = start_addr + urb->iso_frame_desc[i].offset;
td_len = urb->iso_frame_desc[i].length;
td_remain_len = td_len;
- /* FIXME: Ignoring zero-length packets, can those happen? */
total_packet_count = roundup(td_len,
- le16_to_cpu(urb->ep->desc.wMaxPacketSize));
+ usb_endpoint_maxp(&urb->ep->desc));
+ /* A zero-length transfer still involves at least one packet. */
+ if (total_packet_count == 0)
+ total_packet_count++;
burst_count = xhci_get_burst_count(xhci, urb->dev, urb,
total_packet_count);
residue = xhci_get_last_burst_packet_count(xhci,
^ permalink raw reply
* linux-next: build failure after merge of the staging tree
From: Stephen Rothwell @ 2011-08-25 5:02 UTC (permalink / raw)
To: Greg KH
Cc: linux-next, linux-kernel, wlanfae, Larry Finger, Jiri Pirko,
David Miller, netdev
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
Caused by commit 94a799425eee ("From: wlanfae <wlanfae@realtek.com>" -
really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek"
Larry, that patch was badly imported ...) interacting with commit
b81693d9149c ("net: remove ndo_set_multicast_list callback") from the net
tree.
I applied the following patch (which seems to be what was done to the
other drivers in the net tree - there is probably more required):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Aug 2011 14:57:55 +1000
Subject: [PATCH] rtl8192e: update for ndo_set_multicast_list removal.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8192e/rtl_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
index f8a13d9..b38f626 100644
--- a/drivers/staging/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl_core.c
@@ -2914,7 +2914,7 @@ static const struct net_device_ops rtl8192_netdev_ops = {
.ndo_stop = rtl8192_close,
.ndo_tx_timeout = rtl8192_tx_timeout,
.ndo_do_ioctl = rtl8192_ioctl,
- .ndo_set_multicast_list = r8192_set_multicast,
+ .ndo_set_rx_mode = r8192_set_multicast,
.ndo_set_mac_address = r8192_set_mac_adr,
.ndo_validate_addr = eth_validate_addr,
.ndo_change_mtu = eth_change_mtu,
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [Patch] numa: introduce CONFIG_NUMA_SYSFS for drivers/base/node.c
From: David Rientjes @ 2011-08-25 5:04 UTC (permalink / raw)
To: Randy Dunlap
Cc: Cong Wang, Andrew Morton, Stephen Rothwell, gregkh, linux-next,
LKML, linux-mm
In-Reply-To: <20110824205044.7ff45b6c.rdunlap@xenotime.net>
On Wed, 24 Aug 2011, Randy Dunlap wrote:
> > Below is the updated version.
> >
> > Thanks for testing!
>
> Yes, that works after changing #ifdef defined(...)
> to #if defined(...)
>
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
>
No, it doesn't work, CONFIG_HUGETLBFS can be enabled with CONFIG_NUMA=y
and CONFIG_SYSFS=n and that uses data structures from drivers/base/node.c
which doesn't get compiled with this patch.
^ permalink raw reply
* Re: linux-next: build warning after merge of the rcu tree
From: Paul E. McKenney @ 2011-08-25 5:04 UTC (permalink / raw)
To: Arnaud Lacombe; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <CACqU3MVZRjxo-C+z-WRKnMMFfkr35c4FDUpoY6Kbkh1y1J45kQ@mail.gmail.com>
On Wed, Aug 24, 2011 at 08:46:15PM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Wed, Aug 24, 2011 at 8:27 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Wed, Aug 24, 2011 at 02:23:37PM +1000, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> After merging the rcu tree, today's linux-next build (powerpc
> >> ppc64_defconfig) produced this warning:
> >>
> >> kernel/rtmutex.c: In function '__rt_mutex_slowlock':
> >> kernel/rtmutex.c:605:3: warning: suggest parentheses around assignment used as truth value
> >
> > There actually already are parentheses around it, and the first pass
> > through the loop it is uninitialized at that point. But hey, that
> > is gcc for you! Does the patch below cure it?
> >
> Yes.
Thank you!
Thanx, Paul
> - Arnaud
>
> >> Introduced by commit 83841f021d4b ("rcu: Permit rt_mutex_unlock() with
> >> irqs disabled").
> >
> > If it does, then I will fold into that commit.
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
> > index 0222e34..2548f44 100644
> > --- a/kernel/rtmutex.c
> > +++ b/kernel/rtmutex.c
> > @@ -602,7 +602,8 @@ __rt_mutex_slowlock(struct rt_mutex *lock, int state,
> >
> > raw_spin_unlock(&lock->wait_lock);
> >
> > - if (was_disabled = irqs_disabled())
> > + was_disabled = irqs_disabled();
> > + if (was_disabled)
> > local_irq_enable();
> >
> > debug_rt_mutex_print_deadlock(waiter);
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
^ permalink raw reply
* Re: linux-next: build failure after merge of the staging tree
From: Larry Finger @ 2011-08-25 5:15 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Greg KH, linux-next, linux-kernel, wlanfae, Jiri Pirko,
David Miller, netdev
In-Reply-To: <20110825150209.5d159c549777290de4644bcf@canb.auug.org.au>
On 08/25/2011 12:02 AM, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/staging/rtl8192e/rtl_core.c:2917:2: error: unknown field 'ndo_set_multicast_list' specified in initializer
>
> Caused by commit 94a799425eee ("From: wlanfae<wlanfae@realtek.com>" -
> really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek"
> Larry, that patch was badly imported ...) interacting with commit
> b81693d9149c ("net: remove ndo_set_multicast_list callback") from the net
> tree.
>
> I applied the following patch (which seems to be what was done to the
> other drivers in the net tree - there is probably more required):
>
> From: Stephen Rothwell<sfr@canb.auug.org.au>
> Date: Thu, 25 Aug 2011 14:57:55 +1000
> Subject: [PATCH] rtl8192e: update for ndo_set_multicast_list removal.
>
> Signed-off-by: Stephen Rothwell<sfr@canb.auug.org.au>
> ---
> drivers/staging/rtl8192e/rtl_core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
> index f8a13d9..b38f626 100644
> --- a/drivers/staging/rtl8192e/rtl_core.c
> +++ b/drivers/staging/rtl8192e/rtl_core.c
> @@ -2914,7 +2914,7 @@ static const struct net_device_ops rtl8192_netdev_ops = {
> .ndo_stop = rtl8192_close,
> .ndo_tx_timeout = rtl8192_tx_timeout,
> .ndo_do_ioctl = rtl8192_ioctl,
> - .ndo_set_multicast_list = r8192_set_multicast,
> + .ndo_set_rx_mode = r8192_set_multicast,
> .ndo_set_mac_address = r8192_set_mac_adr,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_change_mtu = eth_change_mtu,
Stephan,
Thanks for the notice. It seems that commit b81693d9149c had not made it into my
copy of staging. I'll look into the issue.
Larry
^ permalink raw reply
* linux-next: manual merge of the moduleh tree with the arm tree
From: Stephen Rothwell @ 2011-08-25 5:17 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-next, linux-kernel, Jon Medhurst, Russell King
Hi Paul,
Today's linux-next merge of the moduleh tree got a conflict in
arch/arm/mach-bcmring/mm.c between commit 2d5e975b2194 ("ARM:
mach-bcmring: Setup consistent dma size at boot time") from the arm tree
and commit 9bc7d81e271e ("arm: fix implicit use of page.h in
mach-bcmring/mach-jornada") from the moduleh tree.
Jst context changes I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/arm/mach-bcmring/mm.c
index 8616876,293b6d3..0000000
--- a/arch/arm/mach-bcmring/mm.c
+++ b/arch/arm/mach-bcmring/mm.c
@@@ -13,7 -13,7 +13,8 @@@
*****************************************************************************/
#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+ #include <asm/page.h>
#include <asm/mach/map.h>
#include <mach/hardware.h>
^ permalink raw reply
* linux-next: manual merge of the moduleh tree with the lt-mtd tree
From: Stephen Rothwell @ 2011-08-25 5:23 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-next, linux-kernel, Brian Norris, Artem Bityutskiy
Hi Paul,
Today's linux-next merge of the moduleh tree got a conflict in
include/linux/mtd/mtd.h between commit 7f338a9bf785 ("mtd: style fixups
in multi-line comment, indentation") from the l2-mtd tree and commit
089f5643ba44 ("include: replace linux/module.h with "struct module"
wherever possible") from the moduleh tree.
Just context changes. I fixed it up (see below) and can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/mtd/mtd.h
index ff7bae0,af31170..0000000
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@@ -41,11 -40,11 +40,13 @@@
#define MTD_FAIL_ADDR_UNKNOWN -1LL
+ struct module;
+
-/* If the erase fails, fail_addr might indicate exactly which block failed. If
- fail_addr = MTD_FAIL_ADDR_UNKNOWN, the failure was not at the device level or was not
- specific to any particular block. */
+/*
+ * If the erase fails, fail_addr might indicate exactly which block failed. If
+ * fail_addr = MTD_FAIL_ADDR_UNKNOWN, the failure was not at the device level
+ * or was not specific to any particular block.
+ */
struct erase_info {
struct mtd_info *mtd;
uint64_t addr;
^ permalink raw reply
* [patch] numa: fix NUMA compile error when sysfs and procfs are disabled
From: David Rientjes @ 2011-08-25 5:55 UTC (permalink / raw)
To: Andrew Morton, Cong Wang
Cc: Randy Dunlap, Stephen Rothwell, Greg Kroah-Hartman, linux-next,
LKML, linux-mm
In-Reply-To: <4E55C221.8080100@redhat.com>
On Thu, 25 Aug 2011, Cong Wang wrote:
> Ah, this is because I missed the part in include/linux/node.h. :)
>
> Below is the updated version.
>
I've never had a problem building a kernel with CONFIG_NUMA=y and
CONFIG_SYSFS=n since most of drivers/base/node.c is just an abstraction
that calls into sysfs functions that will be no-ops in such a
configuration.
The error you cite in a different thread
(http://marc.info/?l=linux-mm&m=131098795024186) about an undefined
reference to vmstat_text is because you have CONFIG_NUMA enabled and both
CONFIG_SYSFS and CONFIG_PROC_FS disabled and we only define vmstat_text
for those fs configurations since that's the only way these strings were
ever emitted before per-node vmstat.
The correct fix is to define the array for CONFIG_NUMA as well.
numa: fix NUMA compile error when sysfs and procfs are disabled
The vmstat_text array is only defined for CONFIG_SYSFS or CONFIG_PROC_FS,
yet it is referenced for per-node vmstat with CONFIG_NUMA:
drivers/built-in.o: In function `node_read_vmstat':
node.c:(.text+0x1106df): undefined reference to `vmstat_text'
in fa25c503dfa2 (mm: per-node vmstat: show proper vmstats).
Define the array for CONFIG_NUMA as well.
Reported-by: Cong Wang <amwang@redhat.com>
Signed-off-by: David Rientjes <rientjes@google.com>
---
include/linux/vmstat.h | 2 ++
mm/vmstat.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
--- a/include/linux/vmstat.h
+++ b/include/linux/vmstat.h
@@ -258,6 +258,8 @@ static inline void refresh_zone_stat_thresholds(void) { }
#endif /* CONFIG_SMP */
+#if defined(CONFIG_PROC_FS) || defined(CONFIG_SYSFS) || defined(CONFIG_NUMA)
extern const char * const vmstat_text[];
+#endif
#endif /* _LINUX_VMSTAT_H */
diff --git a/mm/vmstat.c b/mm/vmstat.c
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -659,7 +659,7 @@ static void walk_zones_in_node(struct seq_file *m, pg_data_t *pgdat,
}
#endif
-#if defined(CONFIG_PROC_FS) || defined(CONFIG_SYSFS)
+#if defined(CONFIG_PROC_FS) || defined(CONFIG_SYSFS) || defined(CONFIG_NUMA)
#ifdef CONFIG_ZONE_DMA
#define TEXT_FOR_DMA(xx) xx "_dma",
#else
@@ -788,7 +788,7 @@ const char * const vmstat_text[] = {
#endif /* CONFIG_VM_EVENTS_COUNTERS */
};
-#endif /* CONFIG_PROC_FS || CONFIG_SYSFS */
+#endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA */
#ifdef CONFIG_PROC_FS
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* linux-next: build failure after merge of the final tree (staging tree related)
From: Stephen Rothwell @ 2011-08-25 6:17 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Larry Finger, wlanfae
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/staging/rtl8192e/rtl_core.c: In function 'rtl8192_init_priv_variable':
drivers/staging/rtl8192e/rtl_core.c:1270:2: error: implicit declaration of function 'vmalloc'
drivers/staging/rtl8192e/rtl_core.c:1270:20: warning: cast to pointer from integer of different size
drivers/staging/rtl8192e/rtl_core.c: In function 'rtl8192_pci_disconnect':
drivers/staging/rtl8192e/rtl_core.c:3101:4: error: implicit declaration of function 'vfree'
Caused by commit 94a799425eee ("rom: wlanfae <wlanfae@realtek.com>"
really "[PATCH 1/8] rtl8192e: Import new version of driver from realtek").
I have applied this patch for today:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 25 Aug 2011 16:13:02 +1000
Subject: [PATCH] staging/rtl8192e: using vmalloc/vfree requires including
vmalloc.h
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rtl8192e/rtl_core.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl_core.c b/drivers/staging/rtl8192e/rtl_core.c
index b38f626..15ee5ee 100644
--- a/drivers/staging/rtl8192e/rtl_core.c
+++ b/drivers/staging/rtl8192e/rtl_core.c
@@ -43,6 +43,7 @@
#include <asm/uaccess.h>
#include <linux/pci.h>
+#include <linux/vmalloc.h>
#include "rtl_core.h"
#include "r8192E_phy.h"
#include "r8192E_phyreg.h"
--
1.7.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* linux-next: build failure after merge of the final tree (akpm and moduleh trees related)
From: Stephen Rothwell @ 2011-08-25 6:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Yanmin Zhang, Paul Gortmaker
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
Hi all,
After merging the final tree, today's linux-next build (sparc64 defconfig)
failed like this:
kernel/printk.c:536:35: error: expected ')' before string constant
kernel/printk.c:1116:35: error: expected ')' before string constant
Caused by commits 8a04dedc045d ("We are enabling some power features on
medfield. To test suspend-2-RAM") and d09d67ec904c (same - the following
commit) from the akpm tree interacting with commit a25ffe9fafa1 ("kernel:
Map most files to use export.h instead of module.h") from the moduleh
tree. This file now needs module.h, not just export.h since
MODULE_PARM_DESC if defined there.
I have applied a merge fixup patch to change export.h back to module.h.
P.S. Andrew, these commits could do with better subject lines :-(
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2011-08-25 6:18 UTC (permalink / raw)
To: Greg KH; +Cc: linux-next, linux-kernel, Timur Tabi, ppc-dev
[-- Attachment #1: Type: text/plain, Size: 979 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc':
drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' undeclared (first use in this function)
drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write':
drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of different size
drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init':
drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of different size
Caused by commit dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded
hypervisor byte channel driver").
MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is
included by arch/powerpc/include/asm/reg.h but only when defined
(CONFIG_BOOKE) || defined(CONFIG_40x).
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: Tree for Aug 25
From: Stephen Rothwell @ 2011-08-25 6:35 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 24138 bytes --]
Hi all,
The powerpc allyesconfig build still fails today.
Changes since 20110824:
The hid tree gained a conflict against Linus' tree.
The pm tree gained a conflict against the arm tree.
The ptrace tree lost its build failure but gained another so I used the
version from next-20110824 and the revert.
The xen tree gained a conflict against the tip tree that was a bit
complex, so I used the version from next-20110824.
The tty tree lost its build failure but gained another for which I
reverted a commit.
The usb tree gained a conflict against the usb.current tree.
The staging tree lost its build failure but gained 2 more for which I
applied patches.
The moduleh tree gained conflicts against the arm and l2-mtd tree.
The akpm tree gained a build failure (interaction withe the moduleh tree)
for which I applied a patch.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/v2.6/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 199 trees (counting Linus' and 28 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master
Merging fixes/fixes
Merging kbuild-current/rc-fixes
Merging arm-current/master
Merging m68k-current/for-linus
Merging powerpc-merge/merge
Merging 52xx-and-virtex-current/powerpc/merge
Merging sparc-current/master
Merging scsi-rc-fixes/master
Merging net-current/master
Merging sound-current/for-linus
Merging pci-current/for-linus
Merging wireless-current/master
Merging driver-core.current/driver-core-linus
Merging tty.current/tty-linus
Merging usb.current/usb-linus
Merging staging.current/staging-linus
Merging cpufreq-current/fixes
Merging input-current/for-linus
Merging md-current/for-linus
Merging audit-current/for-linus
Merging crypto-current/master
Merging ide-curent/master
Merging dwmw2/master
Merging sh-current/sh-fixes-for-linus
Merging rmobile-current/rmobile-fixes-for-linus
Merging fbdev-current/fbdev-fixes-for-linus
Merging devicetree-current/devicetree/merge
Merging spi-current/spi/merge
Merging arm/for-next
Merging arm-lpae/for-next
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgalloc.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/pgtable.h
CONFLICT (content): Merge conflict in arch/arm/include/asm/tlb.h
CONFLICT (content): Merge conflict in arch/arm/kernel/head.S
CONFLICT (content): Merge conflict in arch/arm/mm/dma-mapping.c
CONFLICT (content): Merge conflict in arch/arm/mm/mmu.c
Merging arm-soc/for-next
Merging at91/at91-next
Merging davinci/davinci-next
Merging i.MX/for-next
Merging linux-spec/for-next
Merging msm/for-next
CONFLICT (content): Merge conflict in arch/arm/mach-msm/io.c
Merging omap/for-next
Merging pxa/for-next
Merging samsung/next-samsung
Merging s5p/for-next
Merging tegra/for-next
Merging ux500-core/ux500-core
Merging xilinx/arm-next
Merging blackfin/for-linus
Merging cris/for-next
Merging ia64/test
Merging m68k/for-next
Merging m68knommu/for-next
Merging microblaze/next
Merging mips/mips-for-linux-next
Merging openrisc/for-upstream
Merging parisc/for-next
Merging powerpc/next
Merging 4xx/next
Merging 52xx-and-virtex/powerpc/next
Merging galak/next
Merging s390/features
Merging sh/sh-latest
Merging rmobile/rmobile-latest
Merging sparc/master
Merging tile/master
Merging unicore32/unicore32
Merging xtensa/master
Merging ceph/for-next
Merging cifs/master
Merging configfs/linux-next
Merging ecryptfs/next
Merging ext3/for_next
Merging ext4/dev
Merging fatfs/master
Merging fuse/for-next
Merging gfs2/master
Merging hfsplus/for-next
Merging jfs/next
Merging logfs/master
Merging nfs/linux-next
Merging nfsd/nfsd-next
Merging nilfs2/for-next
Merging ocfs2/linux-next
Merging omfs/for-next
Merging squashfs/master
Merging udf/for_next
Merging v9fs/for-next
Merging ubifs/linux-next
Merging xfs/master
Merging vfs/for-next
Merging vfs-scale/vfs-scale-working
Merging pci/linux-next
Merging hid/for-next
CONFLICT (content): Merge conflict in drivers/hid/hid-core.c
CONFLICT (content): Merge conflict in drivers/hid/hid-ids.h
Merging quilt/i2c
Merging bjdooks-i2c/next-i2c
Merging quilt/jdelvare-hwmon
Merging hwmon-staging/hwmon-next
Merging quilt/kernel-doc
Merging docs/docs-move
Merging v4l-dvb/master
Merging kbuild/for-next
Merging kconfig/for-next
Merging ide/master
Merging libata/NEXT
Merging infiniband/for-next
Merging acpi/test
Merging idle-test/idle-test
Merging powertools/tools-test
Merging cpupowerutils/master
Merging ieee1394/for-next
Merging ubi/linux-next
Merging dlm/next
Merging swiotlb/master
Merging ibft/master
Merging scsi/master
Merging iscsi-target/for-next
Merging slave-dma/next
Merging async_tx/next
Merging net/master
CONFLICT (delete/modify): arch/powerpc/configs/40x/hcu4_defconfig deleted in HEAD and modified in net/master. Version net/master of arch/powerpc/configs/40x/hcu4_defconfig left in tree.
CONFLICT (content): Merge conflict in drivers/net/Kconfig
CONFLICT (content): Merge conflict in drivers/net/Makefile
$ git rm -f arch/powerpc/configs/40x/hcu4_defconfig
Applying: powerpc: update ppc64_defconfig for net device movement
Applying: sparc: update sparc32_defconfig for net device movement
Applying: sparc: update sparc64_defconfig for net device movement
Merging wireless/master
Merging bluetooth/master
Merging mtd/master
Merging l2-mtd/master
CONFLICT (content): Merge conflict in drivers/mtd/maps/lantiq-flash.c
Merging crypto/master
Merging sound/for-next
Merging sound-asoc/for-next
Merging cpufreq/next
Merging quilt/rr
Merging input/next
Merging input-mt/next
Merging lsm/for-next
Merging block/for-next
Merging quilt/device-mapper
Merging embedded/master
Merging firmware/master
Merging pcmcia/master
Merging battery/master
Merging leds/for-mm
CONFLICT (content): Merge conflict in drivers/leds/Kconfig
Merging backlight/for-mm
Merging mmc/mmc-next
Merging kgdb/kgdb-next
Merging slab/for-next
Merging uclinux/for-next
Merging md/for-next
Merging mfd/for-next
Merging hdlc/hdlc-next
Merging drm/drm-next
Merging fbdev/master
Merging viafb/viafb-next
Merging omap_dss2/for-next
Merging voltage/for-next
Merging security/next
CONFLICT (content): Merge conflict in fs/ocfs2/xattr.c
Merging selinux/master
Merging lblnet/master
Merging agp/agp-next
Merging watchdog/master
Merging bdev/master
Merging dwmw2-iommu/master
Merging cputime/cputime
Merging osd/linux-next
Merging jc_docs/docs-next
Merging nommu/master
Merging trivial/for-next
Merging audit/for-next
Merging pm/linux-next
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/board-ap4evb.c
CONFLICT (content): Merge conflict in arch/s390/include/asm/thread_info.h
CONFLICT (content): Merge conflict in drivers/mfd/twl4030-irq.c
Merging apm/for-next
Merging fsnotify/for-next
Merging irda/for-next
Merging i7core_edac/linux_next
Merging i7300_edac/linux_next
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mcheck/mce.c
Merging devicetree/devicetree/next
CONFLICT (content): Merge conflict in drivers/of/base.c
Merging spi/spi/next
Merging gpio/gpio/next
Merging tip/auto-latest
CONFLICT (content): Merge conflict in arch/x86/mm/fault.c
Merging rcu/rcu/next
Merging kvm/linux-next
Merging oprofile/for-next
Merging ptrace/ptrace
$ git reset --hard HEAD^
Merging refs/next/20110824/ptrace
[master 1e1a076] Revert "signal: Add block_sigmask() for adding sigmask to current->blocked"
Merging xen/upstream/xen
CONFLICT (content): Merge conflict in arch/x86/include/asm/spinlock.h
$ git reset --hard
Merging "refs/next/20110824/xen"
Merging xen-two/linux-next
Merging xen-pvhvm/linux-next
Merging edac-amd/for-next
Merging percpu/for-next
Merging workqueues/for-next
Merging sfi/sfi-test
Merging asm-generic/next
Merging drivers-x86/linux-next
Merging hwpoison/hwpoison
Merging sysctl/master
Merging namespace/master
Merging regmap/for-next
Merging driver-core/driver-core-next
Merging tty/tty-next
Merging usb/usb-next
CONFLICT (content): Merge conflict in drivers/usb/host/xhci-ring.c
Merging staging/staging-next
CONFLICT (content): Merge conflict in drivers/staging/xgifb/XGI_main_26.c
Applying: rtl8192e: update for ndo_set_multicast_list removal.
Merging bkl-config/config
Merging tmem/linux-next
Merging writeback/next
Merging arm-dt/devicetree/arm-next
Merging moduleh/module.h-split
CONFLICT (content): Merge conflict in arch/arm/mach-bcmring/mm.c
CONFLICT (content): Merge conflict in drivers/staging/iio/accel/adis16220_core.c
CONFLICT (content): Merge conflict in include/linux/dmaengine.h
CONFLICT (content): Merge conflict in include/linux/mtd/mtd.h
Applying: dm: use export.h instead of module.h where possible
Applying: block: bsg-lib.c needs export.h not module.h
Applying: PM: EXPORT_SYMBOL needs export.h
Merging kvmtool/master
CONFLICT (content): Merge conflict in include/net/9p/9p.h
Merging scsi-post-merge/merge-base:master
$ git checkout akpm
Applying: Found on allmodconfig build (ARCH=alpha)
Applying: The bug was accidentally found by the following program:
Applying: WARNING: line over 80 characters
Applying: The for loop was looking for i <= 0 instead of i >= 0 so this function
Applying: Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Applying: Commit d1a05b6 ("memcg do not try to drain per-cpu caches without pages")
Applying: Change to new git tree -
Applying: The test for bad usage of min_t() and max_t() is missing the --ignore
Applying: The various basic memory allocation function return NULL, not an ERR_PTR.
Applying: I get below warnning:
Applying: Paul said: I left Google at the end of last week - if it's not bouncing
Applying: It seems that 7bf693951a8e ("console: allow to retain boot console via
Applying: ZONE_CONGESTED is only cleared in kswapd, but pages can be freed in any
Applying: Replace/remove use of RIO v.1.2 registers/bits that are not
Applying: ep93xx_bl.c uses interfaces from linux/module.h,
Applying: Add missing include of linux/module.h for drivers that use interfaces from
Applying: Commit 79dfdac ("memcg: make oom_lock 0 and 1 based rather than counter")
Applying: We need a callback to do some things after pwm_enable, pwm_disable
Applying: This is a i2c driver, not a platform driver, thus use "i2c" prefix for the
Applying: Make sure we are passing the same cookie in all calls to
Applying: Since 43cc71eed1250 ("platform: prefix MODALIAS with "platform:""), the
Applying: Fix the following build errors:
Applying: bd2802_unregister_led_classdev() should unregister all registered
Applying: Because of x86-implement-strict-user-copy-checks-for-x86_64.patch
Applying: When no floppy is found the module code can be released while a timer
Applying: Fix kconfig unmet dependency warning. BACKLIGHT_CLASS_DEVICE depends on
Applying: Fix the following memory leak:
Applying: The parameter's origin type is long. On an i386 architecture, it can
Applying: Since the commit below which added O_PATH support to the *at() calls, the
Applying: Add support for Aspire 1410 BIOS v1.3314. Fixes the following error:
Applying: This makes the iris driver use the platform API, so it is properly exposed
Applying: On x86_32 casting the unsigned int result of get_random_int() to long may
Applying: This new driver replaces the old PCEngines Alix 2/3 LED driver with a new
Applying: Cc: Ed Wildgoose <git@wildgooses.com>
Applying: Replace the bubble sort in sanitize_e820_map() with a call to the generic
Applying: The x86 timer interrupt handler is the only handler not traced in the
Applying: The current interrupt traces from irq_handler_entry and irq_handler_exit
Applying: Don't allow everybody to use a modem.
Applying: The address limit is already set in flush_old_exec() so this
Applying: A call to va_copy() should always be followed by a call to va_end() in the
Applying: Don't dereference em if it's NULL or an error pointer.
Applying: The RETE bit in IECSR is cleared by writing a 1 to it.
Applying: Some messing with error codes to return 0 on out id's and match
Applying: kbuf is a buffer that is local to this function, so all of the error paths
Applying: fb_set_suspend() must be called with the console semaphore held, which
Applying: hwmon was using an idr with a NULL pointer, so convert to an
Applying: A straightforward looking use of idr for a device id.
Applying: This patchset aims at addressing /proc/stat issue which has been
Applying: update_ts_time_stat currently updates idle time even if we are in iowait
Applying: get_cpu_{idle,iowait}_time_us update idle/iowait counters unconditionally
Applying: show_stat handler of the /proc/stat file relies on kstat_cpu(cpu)
Applying: The address limit is already set in flush_old_exec() so this
Applying: The address limit is already set in flush_old_exec() so this
Applying: Add new check (assert_init) to make sure objects are initialized and
Applying: del_timer_sync() calls debug_object_assert_init() to assert that a timer
Applying: ext4_{set,clear}_bit() is defined as __test_and_{set,clear}_bit_le() for
Applying: The dqc_bitmap field of struct ocfs2_local_disk_chunk is 32-bit aligned,
Applying: The address limit is already set in flush_old_exec() so those calls to
Applying: When do pci remove/rescan on system that have more iommus, got
Applying: The current implementation of dmi_name_in_vendors() is an invitation to
Applying: kernel/rtmutex.c: In function '__rt_mutex_slowlock':
Applying: For headers that get exported to userland and make use of u32 style
Applying: Fix sparse warnings of right shift bigger than source value size:
Applying: We leak in drivers/scsi/aacraid/commctrl.c::aac_send_raw_srb() :
Applying: Some mangling of errors was necessary to maintain current interface.
Applying: This does involve additional use of the spin lock in idr.c. Is this an
Applying: Instead of open coding this function use kstrtoul_from_user() directly.
Applying: brd_make_request() always returns 0, which doesn't make much sense.
Applying: The address limit is already set in flush_old_exec() so this assignment of
Applying: Unbreak the alpha build.
Applying: Unbreak alpha build.
Applying: Unbreak alpha build.
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: When we get corruption reports, it's useful to see if the kernel was
Applying: The basic idea behind cross memory attach is to allow MPI programs doing
Applying: - Add x86_64 specific wire up
Applying: > You might get some speed benefit by optimising for the small copies
Applying: acct_isolated of compaction uses page_lru_base_type which returns only
Applying: Change ISOLATE_XXX macro with bitwise isolate_mode_t type. Normally,
Applying: In async mode, compaction doesn't migrate dirty or writeback pages. So,
Applying: In __zone_reclaim case, we don't want to shrink mapped page. Nonetheless,
Applying: unmap_and_move() is one a big messy function. Clean it up.
Applying: radix_tree_tag_get()'s BUG (when it sees a tag after saw_unset_tag) was
Applying: per-task block plug can reduce block queue lock contention and increase
Applying: The tracing ring-buffer used this function briefly, but not anymore.
Applying: After selecting a task to kill, the oom killer iterates all processes and
Applying: Add the leading word "tmpfs" to the Kconfig string to make it blindingly
Applying: When we get a bad_page bug report, it's useful to see what modules the
Applying: Without swap, anonymous pages are not scanned. As such, they should not
Applying: fix comment
Applying: The nr_force_scan[] tuple holds the effective scan numbers for anon and
Applying: Some kernel components pin user space memory (infiniband and perf) (by
Applying: Add comments to explain the page statistics field in the mm_struct.
Applying: add missing ;
Applying: Testing from the XFS folk revealed that there is still too much I/O from
Applying: Lumpy reclaim worked with two passes - the first which queued pages for IO
Applying: Direct reclaim should never writeback pages. For now, handle the
Applying: Direct reclaim should never writeback pages. Warn if an attempt is made.
Applying: It is preferable that no dirty pages are dispatched for cleaning from the
Applying: Workloads that are allocating frequently and writing files place a large
Applying: When direct reclaim encounters a dirty page, it gets recycled around the
Applying: It's possible a zone watermark is ok when entering the balance_pgdat()
Applying: printk_ratelimit() should not be used, because it shares ratelimiting
Applying: memchr_inv() is mainly used to check whether the whole buffer is filled
Applying: Use newly introduced memchr_inv() for page verification.
Applying: A shrinker function can return -1, means that it cannot do anything
Applying: Use atomic-long operations instead of looping around cmpxchg().
Applying: massage atomic.h inclusions
Applying: The /proc/vmallocinfo shows information about vmalloc allocations in
Applying: Commit 645747462435 ("vmscan: detect mapped file pages used only once")
Applying: Logic added in commit 8cab4754d24a0 ("vmscan: make mapped executable pages
Applying: SPARC32 require access to the start address. Add a new helper
Applying: With the NO_BOOTMEM symbol added architectures may now use the following
Applying: Using "- 1" relies on the old_end to be page aligned and PAGE_SIZE > 1,
Applying: This replaces ptep_clear_flush() with ptep_get_and_clear() and a single
Applying: This adds THP support to mremap (decreases the number of split_huge_page()
Applying: coding-style nitpicking
Applying: Cc: Andrea Arcangeli <aarcange@redhat.com>
Applying: Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applying: vmstat_text is only available when PROC_FS or SYSFS is enabled. This
Applying: reduce ifdeffery
Applying: Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applying: Make the security_inode_init_security() initxattrs arg const, to match the
Applying: The current implementation of the /dev/hpet driver couples opening the
Applying: smp_call_function() only lets all other CPUs execute a specific function,
Applying: auto_demotion_disable is called only for online CPUs. For hotplugged
Applying: Enabling DEBUG_STRICT_USER_COPY_CHECKS causes the following warning:
Applying: Strict user copy checks are only really supported on x86_32 even though
Applying: The help text for this config is duplicated across the x86, parisc, and
Applying: s/lib-/obj-/ for usercopy.o
Applying: After an "unexpected" reboot, I found this Oops in my logs:
Applying: In the move of the lis3 driver, the hp_accel.c file got dropped from the
Applying: Add axis correction for HP EliteBook 2730p.
Applying: Add axis correction for HP EliteBook 8540w.
Applying: Add axis correction for HP ProBook 6555b.
Applying: Adapt the help text for CONFIG_HP_ACCEL to the move of
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: Change exported functions to use the device given as parameter
Applying: Signed-off-by: Ilkka Koskinen <ilkka.koskinen@nokia.com>
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: We are enabling some power features on medfield. To test suspend-2-RAM
Applying: Cc: Al Viro <viro@zeniv.linux.org.uk>
Applying: Add V2 of the LED driver for a single timer channel for the TPU hardware
Applying: include linux/module.h
Applying: The memory for struct led_trigger should be kfreed in the
Applying: Currently termination logic (\0 or \n\0) is hardcoded in _kstrtoull(),
Applying: Add support for slice by 8 to existing crc32 algorithm. Also modify
Applying: don't include asm/msr.h
Applying: epoll can acquire recursively acquire ep->mtx on multiple "struct
Applying: Currently in oprofilefs, files that use ulong_fops mis-handle writes of
Applying: This is the one use of an ida that doesn't retry on receiving -EAGAIN.
Applying: One can get this information from minix/inode.c, but adding the
Applying: The memcg code sometimes uses "struct mem_cgroup *mem" and sometimes uses
Applying: Before calling schedule_timeout(), task state should be changed.
Applying: Signed-off-by: Bob Liu <lliubbo@gmail.com>
Applying: While back-porting Johannes Weiner's patch "mm: memcg-aware global
Applying: If somebody is touching data too early, it might be easier to diagnose a
Applying: Both mem_cgroup_charge_statistics() and mem_cgroup_move_account() were
Applying: On reading sysctl dirs we should return -EISDIR instead of -EINVAL.
Applying: Force this on for -next/mm testing purposes.
Applying: Expand root=PARTUUID=UUID syntax to support selecting a root partition by
Applying: After merging the akpm tree, today's linux-next build (lost of them)
Applying: The discovered bit in PGCCSR register indicates if the device has been
Applying: Add RapidIO mport driver for IDT TSI721 PCI Express-to-SRIO bridge device.
Applying: When I tried to send a patch to remove it, Andi told me we still need to
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: This is only an error, no need to use KERN_CRIT log level.
Applying: Signed-off-by: WANG Cong <amwang@redhat.com>
Applying: ERROR: code indent should use tabs where possible
Applying: A default echo function has been provided so it is no longer an error when
Applying: This client driver allows you to use a GPIO pin as a source for PPS
Applying: remove unneeded cast of void*
Applying: Straightforward. As an aside, the ida_init calls are not needed as far as
Applying: Simply creates one point to call the w1 interface.
Applying: Adds a nolock function to the w1 interface to avoid locking the
Applying: Fixes the deadlock when inserting and removing the ds2780.
Merging akpm
Applying: printk.c now needs module.s not justy export.h
[master 91f13d7] Revert "tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver"
Applying: staging/tl8192e: using vmalloc/vfree requires including vmalloc.h
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: KAMEZAWA Hiroyuki @ 2011-08-25 7:13 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, mm-commits, linux-mm, linux-fsdevel, linux-next
In-Reply-To: <201108242148.p7OLm1lt009191@imap1.linux-foundation.org>
On Wed, 24 Aug 2011 14:09:05 -0700
akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
>
> It contains the following patches against 3.1-rc3:
> (patches marked "*" will be included in linux-next)
>
just reporting.
A compile error from linux-next.patch.
drivers/built-in.o: In function `dwc3_testmode_open':
/home/kamezawa/Kernel/mmotm-Aug24/drivers/usb/dwc3/debugfs.c:481: undefined reference to `dwc3_send_gadget_ep_cmd'
/home/kamezawa/Kernel/mmotm-Aug24/drivers/usb/dwc3/debugfs.c:482: undefined reference to `dwc3_send_gadget_ep_cmd'
make: *** [.tmp_vmlinux1] Error
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Patch] numa: introduce CONFIG_NUMA_SYSFS for drivers/base/node.c
From: Cong Wang @ 2011-08-25 10:22 UTC (permalink / raw)
To: David Rientjes
Cc: Randy Dunlap, Andrew Morton, Stephen Rothwell, gregkh, linux-next,
LKML, linux-mm
In-Reply-To: <alpine.DEB.2.00.1108242202050.576@chino.kir.corp.google.com>
于 2011年08月25日 13:04, David Rientjes 写道:
> On Wed, 24 Aug 2011, Randy Dunlap wrote:
>
>>> Below is the updated version.
>>>
>>> Thanks for testing!
>>
>> Yes, that works after changing #ifdef defined(...)
>> to #if defined(...)
>>
>> Acked-by: Randy Dunlap<rdunlap@xenotime.net>
>>
>
> No, it doesn't work, CONFIG_HUGETLBFS can be enabled with CONFIG_NUMA=y
> and CONFIG_SYSFS=n and that uses data structures from drivers/base/node.c
> which doesn't get compiled with this patch.
So, you mean with CONFIG_NUMA=y && CONFIG_SYSFS=n && CONFIG_HUGETLBFS=y
we still get compile error?
Which data structures are used by hugetlbfs?
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Michal Hocko @ 2011-08-25 13:51 UTC (permalink / raw)
To: akpm; +Cc: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next
In-Reply-To: <201108242148.p7OLm1lt009191@imap1.linux-foundation.org>
Hi Andrew,
On Wed 24-08-11 14:09:05, Andrew Morton wrote:
> The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
I have just downloaded your tree and cannot quilt it up. I am getting:
[...]
patching file tools/power/cpupower/debug/x86_64/centrino-decode.c
Hunk #1 FAILED at 1.
File tools/power/cpupower/debug/x86_64/centrino-decode.c is not empty after patch, as expected
1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/centrino-decode.c
patching file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
Hunk #1 FAILED at 1.
File tools/power/cpupower/debug/x86_64/powernow-k8-decode.c is not empty after patch, as expected
1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
[...]
patching file virt/kvm/iommu.c
Patch linux-next.patch does not apply (enforce with -f)
Is this a patch (I am using 2.6.1) issue? The failing hunk looks as
follows:
--- a/tools/power/cpupower/debug/x86_64/centrino-decode.c
+++ /dev/null
@@ -1 +0,0 @@
-../i386/centrino-decode.c
\ No newline at end of file
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Michal Hocko @ 2011-08-25 14:07 UTC (permalink / raw)
To: akpm; +Cc: mm-commits, linux-kernel, linux-mm, linux-fsdevel, linux-next
In-Reply-To: <20110825135103.GA6431@tiehlicka.suse.cz>
On Thu 25-08-11 15:51:03, Michal Hocko wrote:
> Hi Andrew,
>
> On Wed 24-08-11 14:09:05, Andrew Morton wrote:
> > The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
>
> I have just downloaded your tree and cannot quilt it up. I am getting:
> [...]
> patching file tools/power/cpupower/debug/x86_64/centrino-decode.c
> Hunk #1 FAILED at 1.
> File tools/power/cpupower/debug/x86_64/centrino-decode.c is not empty after patch, as expected
> 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/centrino-decode.c
> patching file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> Hunk #1 FAILED at 1.
> File tools/power/cpupower/debug/x86_64/powernow-k8-decode.c is not empty after patch, as expected
> 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> [...]
> patching file virt/kvm/iommu.c
> Patch linux-next.patch does not apply (enforce with -f)
>
> Is this a patch (I am using 2.6.1) issue? The failing hunk looks as
> follows:
> --- a/tools/power/cpupower/debug/x86_64/centrino-decode.c
> +++ /dev/null
> @@ -1 +0,0 @@
> -../i386/centrino-decode.c
> \ No newline at end of file
Isn't this just a special form of git (clever) diff to spare some lines
when the file deleted? Or is the patch simply corrupted?
Anyway, my patch doesn't cope with that. Any hint what to do about it?
Thanks
--
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Greg KH @ 2011-08-25 14:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Timur Tabi, ppc-dev
In-Reply-To: <20110825161843.daf46b6b4023926fcfeec387@canb.auug.org.au>
On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the final tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/tty/ehv_bytechan.c: In function 'udbg_init_ehv_bc':
> drivers/tty/ehv_bytechan.c:230:18: error: 'MSR_GS' undeclared (first use in this function)
> drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write':
> drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of different size
> drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init':
> drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of different size
>
> Caused by commit dcd83aaff1c8 ("tty/powerpc: introduce the ePAPR embedded
> hypervisor byte channel driver").
>
> MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is
> included by arch/powerpc/include/asm/reg.h but only when defined
> (CONFIG_BOOKE) || defined(CONFIG_40x).
Thanks for the report.
Timur, care to send a fixup patch for this so this gets resolved?
greg k-h
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Timur Tabi @ 2011-08-25 14:28 UTC (permalink / raw)
To: Greg KH
Cc: Stephen Rothwell, <linux-next@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, ppc-dev
In-Reply-To: <20110825140820.GA9126@kroah.com>
On Aug 25, 2011, at 9:08 AM, Greg KH <greg@kroah.com> wrote:
> On Thu, Aug 25, 2011 at 04:18:43PM +1000, Stephen Rothwell wrote:
>>
>
> Thanks for the report.
>
> Timur, care to send a fixup patch for this so this gets resolved?
Yes, I will do it ASAP, probably within the next two hours.
>
^ permalink raw reply
* Re: linux-next: manual merge of the pm tree with the arm tree
From: Rafael J. Wysocki @ 2011-08-25 14:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jon Medhurst, Russell King
In-Reply-To: <20110825133014.4ca16d7b383f7582c7a52d46@canb.auug.org.au>
On Thursday, August 25, 2011, Stephen Rothwell wrote:
> Hi Rafael,
>
> Today's linux-next merge of the pm tree got a conflict in
> arch/arm/mach-shmobile/board-ap4evb.c between commit 9b742024026c ("ARM:
> mach-shmobile: Setup consistent dma size at boot time") from the arm tree
> and commit 2f82df20d71c ("PM: Move clock-related definitions and headers
> to separate file") from the pm tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix as
> necessary.
Thanks a lot!
^ permalink raw reply
* Re: linux-next: build failure after merge of the ptrace tree
From: Oleg Nesterov @ 2011-08-25 14:37 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Tejun Heo, linux-next, linux-kernel, Matt Fleming
In-Reply-To: <20110825141212.4f82835beaad506553e291e8@canb.auug.org.au>
Hi Stephen,
On 08/25, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the ptrace tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: ".set_current_blocked" [fs/autofs4/autofs4.ko] undefined!
In case you didn't notice, we are doing our best to complicate
your life :/
Sorry.
> Presumably set_current_blocked() needs to be EXPORTed.
Yes. I've reset the last 4 commits which touch the code in fs/.
Will add them back after the patch which exports set_current_blocked.
Thanks a lot!
Oleg.
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Stephen Rothwell @ 2011-08-25 15:09 UTC (permalink / raw)
To: Michal Hocko
Cc: akpm, mm-commits, linux-kernel, linux-mm, linux-fsdevel,
linux-next
In-Reply-To: <20110825140701.GA6838@tiehlicka.suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1778 bytes --]
Hi,
On Thu, 25 Aug 2011 16:07:01 +0200 Michal Hocko <mhocko@suse.cz> wrote:
>
> On Thu 25-08-11 15:51:03, Michal Hocko wrote:
> >
> > On Wed 24-08-11 14:09:05, Andrew Morton wrote:
> > > The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > I have just downloaded your tree and cannot quilt it up. I am getting:
> > [...]
> > patching file tools/power/cpupower/debug/x86_64/centrino-decode.c
> > Hunk #1 FAILED at 1.
> > File tools/power/cpupower/debug/x86_64/centrino-decode.c is not empty after patch, as expected
> > 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/centrino-decode.c
> > patching file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> > Hunk #1 FAILED at 1.
> > File tools/power/cpupower/debug/x86_64/powernow-k8-decode.c is not empty after patch, as expected
> > 1 out of 1 hunk FAILED -- rejects in file tools/power/cpupower/debug/x86_64/powernow-k8-decode.c
> > [...]
> > patching file virt/kvm/iommu.c
> > Patch linux-next.patch does not apply (enforce with -f)
> >
> > Is this a patch (I am using 2.6.1) issue? The failing hunk looks as
> > follows:
> > --- a/tools/power/cpupower/debug/x86_64/centrino-decode.c
> > +++ /dev/null
> > @@ -1 +0,0 @@
> > -../i386/centrino-decode.c
> > \ No newline at end of file
>
> Isn't this just a special form of git (clever) diff to spare some lines
> when the file deleted? Or is the patch simply corrupted?
> Anyway, my patch doesn't cope with that. Any hint what to do about it?
Those files were symlinks and were removed by a commit in linux-next.
diff/patch does not cope with that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Randy Dunlap @ 2011-08-25 15:18 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, akpm, mm-commits, linux-mm, linux-fsdevel,
linux-next
In-Reply-To: <20110825161307.7c921e46.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, 25 Aug 2011 16:13:07 +0900 KAMEZAWA Hiroyuki wrote:
> On Wed, 24 Aug 2011 14:09:05 -0700
> akpm@linux-foundation.org wrote:
>
> > The mm-of-the-moment snapshot 2011-08-24-14-08 has been uploaded to
> >
> > http://userweb.kernel.org/~akpm/mmotm/
> >
> > It contains the following patches against 3.1-rc3:
> > (patches marked "*" will be included in linux-next)
> >
>
> just reporting.
>
> A compile error from linux-next.patch.
>
> drivers/built-in.o: In function `dwc3_testmode_open':
> /home/kamezawa/Kernel/mmotm-Aug24/drivers/usb/dwc3/debugfs.c:481: undefined reference to `dwc3_send_gadget_ep_cmd'
> /home/kamezawa/Kernel/mmotm-Aug24/drivers/usb/dwc3/debugfs.c:482: undefined reference to `dwc3_send_gadget_ep_cmd'
> make: *** [.tmp_vmlinux1] Error
Yes, I've sent GregKH a patch for this against linux-next.
thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Timur Tabi @ 2011-08-25 15:22 UTC (permalink / raw)
To: Greg KH; +Cc: Stephen Rothwell, linux-next, linux-kernel, ppc-dev
In-Reply-To: <20110825140820.GA9126@kroah.com>
Greg KH wrote:
>> > MSR_GS is defined in arch/powerpc/include/asm/reg_booke.h which is
>> > included by arch/powerpc/include/asm/reg.h but only when defined
>> > (CONFIG_BOOKE) || defined(CONFIG_40x).
> Thanks for the report.
>
> Timur, care to send a fixup patch for this so this gets resolved?
Is there some trick to building allyesconfig on PowerPC? When I do try that, I
get all sorts of weird build errors, and it dies long before it gets to my
driver. I get stuff like:
LD arch/powerpc/sysdev/xics/built-in.o
WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in
reference from the function .icp_native_init() to the function
.init.text:.icp_native_init_one_node()
The function .icp_native_init() references
the function __init .icp_native_init_one_node().
This is often because .icp_native_init lacks a __init
annotation or the annotation of .icp_native_init_one_node is wrong.
and
AS arch/powerpc/kernel/head_64.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1151: Error: attempt to move .org backwards
arch/powerpc/kernel/exceptions-64s.S:1160: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
I guess I don't have the right compiler.
Anyway, I think I know how to fix the break that Stephen is seeing. I will post
a v4 patch in a few minutes.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
From: Timur Tabi @ 2011-08-25 15:32 UTC (permalink / raw)
To: greg, sfr, linux-next, linux-kernel, linuxppc-dev
The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes. This driver provides Linux kernel support for byte
channels via three distinct interfaces:
1) An early-console (udbg) driver. This provides early console output
through a byte channel. The byte channel handle must be specified in a
Kconfig option.
2) A normal console driver. Output is sent to the byte channel designated
for stdout in the device tree. The console driver is for handling kernel
printk calls.
3) A tty driver, which is used to handle user-space input and output. The
byte channel used for the console is designated as the default tty.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/udbg.h | 1 +
arch/powerpc/kernel/udbg.c | 2 +
drivers/tty/Kconfig | 34 ++
drivers/tty/Makefile | 1 +
drivers/tty/ehv_bytechan.c | 888 +++++++++++++++++++++++++++++++++++++++
5 files changed, 926 insertions(+), 0 deletions(-)
create mode 100644 drivers/tty/ehv_bytechan.c
diff --git a/arch/powerpc/include/asm/udbg.h b/arch/powerpc/include/asm/udbg.h
index 93e05d1..5354ae9 100644
--- a/arch/powerpc/include/asm/udbg.h
+++ b/arch/powerpc/include/asm/udbg.h
@@ -54,6 +54,7 @@ extern void __init udbg_init_40x_realmode(void);
extern void __init udbg_init_cpm(void);
extern void __init udbg_init_usbgecko(void);
extern void __init udbg_init_wsp(void);
+extern void __init udbg_init_ehv_bc(void);
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_UDBG_H */
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index faa82c1..b4607a9 100644
--- a/arch/powerpc/kernel/udbg.c
+++ b/arch/powerpc/kernel/udbg.c
@@ -67,6 +67,8 @@ void __init udbg_early_init(void)
udbg_init_usbgecko();
#elif defined(CONFIG_PPC_EARLY_DEBUG_WSP)
udbg_init_wsp();
+#elif defined(CONFIG_PPC_EARLY_DEBUG_EHV_BC)
+ udbg_init_ehv_bc();
#endif
#ifdef CONFIG_PPC_EARLY_DEBUG
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index bd7cc05..535af0a 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -350,3 +350,37 @@ config TRACE_SINK
If you select this option, you need to select
"Trace data router for MIPI P1149.7 cJTAG standard".
+
+config PPC_EPAPR_HV_BYTECHAN
+ tristate "ePAPR hypervisor byte channel driver"
+ depends on FSL_SOC
+ help
+ This driver creates /dev entries for each ePAPR hypervisor byte
+ channel, thereby allowing applications to communicate with byte
+ channels as if they were serial ports.
+
+config PPC_EARLY_DEBUG_EHV_BC
+ bool "Early console (udbg) support for ePAPR hypervisors"
+ depends on PPC_EPAPR_HV_BYTECHAN
+ help
+ Select this option to enable early console (a.k.a. "udbg") support
+ via an ePAPR byte channel. You also need to choose the byte channel
+ handle below.
+
+config PPC_EARLY_DEBUG_EHV_BC_HANDLE
+ int "Byte channel handle for early console (udbg)"
+ depends on PPC_EARLY_DEBUG_EHV_BC
+ default 0
+ help
+ If you want early console (udbg) output through a byte channel,
+ specify the handle of the byte channel to use.
+
+ For this to work, the byte channel driver must be compiled
+ in-kernel, not as a module.
+
+ Note that only one early console driver can be enabled, so don't
+ enable any others if you enable this one.
+
+ If the number you specify is not a valid byte channel handle, then
+ there simply will be no early console output. This is true also
+ if you don't boot under a hypervisor at all.
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index ea89b0b..2953059 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_ROCKETPORT) += rocket.o
obj-$(CONFIG_SYNCLINK_GT) += synclink_gt.o
obj-$(CONFIG_SYNCLINKMP) += synclinkmp.o
obj-$(CONFIG_SYNCLINK) += synclink.o
+obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
obj-y += ipwireless/
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
new file mode 100644
index 0000000..e67f70b
--- /dev/null
+++ b/drivers/tty/ehv_bytechan.c
@@ -0,0 +1,888 @@
+/* ePAPR hypervisor byte channel device driver
+ *
+ * Copyright 2009-2011 Freescale Semiconductor, Inc.
+ *
+ * Author: Timur Tabi <timur@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ *
+ * This driver support three distinct interfaces, all of which are related to
+ * ePAPR hypervisor byte channels.
+ *
+ * 1) An early-console (udbg) driver. This provides early console output
+ * through a byte channel. The byte channel handle must be specified in a
+ * Kconfig option.
+ *
+ * 2) A normal console driver. Output is sent to the byte channel designated
+ * for stdout in the device tree. The console driver is for handling kernel
+ * printk calls.
+ *
+ * 3) A tty driver, which is used to handle user-space input and output. The
+ * byte channel used for the console is designated as the default tty.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/fs.h>
+#include <linux/poll.h>
+#include <asm/epapr_hcalls.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/cdev.h>
+#include <linux/console.h>
+#include <linux/tty.h>
+#include <linux/tty_flip.h>
+#include <linux/circ_buf.h>
+#include <asm/udbg.h>
+
+/* The size of the transmit circular buffer. This must be a power of two. */
+#define BUF_SIZE 2048
+
+/* Per-byte channel private data */
+struct ehv_bc_data {
+ struct device *dev;
+ struct tty_port port;
+ uint32_t handle;
+ unsigned int rx_irq;
+ unsigned int tx_irq;
+
+ spinlock_t lock; /* lock for transmit buffer */
+ unsigned char buf[BUF_SIZE]; /* transmit circular buffer */
+ unsigned int head; /* circular buffer head */
+ unsigned int tail; /* circular buffer tail */
+
+ int tx_irq_enabled; /* true == TX interrupt is enabled */
+};
+
+/* Array of byte channel objects */
+static struct ehv_bc_data *bcs;
+
+/* Byte channel handle for stdout (and stdin), taken from device tree */
+static unsigned int stdout_bc;
+
+/* Virtual IRQ for the byte channel handle for stdin, taken from device tree */
+static unsigned int stdout_irq;
+
+/**************************** SUPPORT FUNCTIONS ****************************/
+
+/*
+ * Enable the transmit interrupt
+ *
+ * Unlike a serial device, byte channels have no mechanism for disabling their
+ * own receive or transmit interrupts. To emulate that feature, we toggle
+ * the IRQ in the kernel.
+ *
+ * We cannot just blindly call enable_irq() or disable_irq(), because these
+ * calls are reference counted. This means that we cannot call enable_irq()
+ * if interrupts are already enabled. This can happen in two situations:
+ *
+ * 1. The tty layer makes two back-to-back calls to ehv_bc_tty_write()
+ * 2. A transmit interrupt occurs while executing ehv_bc_tx_dequeue()
+ *
+ * To work around this, we keep a flag to tell us if the IRQ is enabled or not.
+ */
+static void enable_tx_interrupt(struct ehv_bc_data *bc)
+{
+ if (!bc->tx_irq_enabled) {
+ enable_irq(bc->tx_irq);
+ bc->tx_irq_enabled = 1;
+ }
+}
+
+static void disable_tx_interrupt(struct ehv_bc_data *bc)
+{
+ if (bc->tx_irq_enabled) {
+ disable_irq_nosync(bc->tx_irq);
+ bc->tx_irq_enabled = 0;
+ }
+}
+
+/*
+ * find the byte channel handle to use for the console
+ *
+ * The byte channel to be used for the console is specified via a "stdout"
+ * property in the /chosen node.
+ *
+ * For compatible with legacy device trees, we also look for a "stdout" alias.
+ */
+static int find_console_handle(void)
+{
+ struct device_node *np, *np2;
+ const char *sprop = NULL;
+ const uint32_t *iprop;
+
+ np = of_find_node_by_path("/chosen");
+ if (np)
+ sprop = of_get_property(np, "stdout-path", NULL);
+
+ if (!np || !sprop) {
+ of_node_put(np);
+ np = of_find_node_by_name(NULL, "aliases");
+ if (np)
+ sprop = of_get_property(np, "stdout", NULL);
+ }
+
+ if (!sprop) {
+ of_node_put(np);
+ return 0;
+ }
+
+ /* We don't care what the aliased node is actually called. We only
+ * care if it's compatible with "epapr,hv-byte-channel", because that
+ * indicates that it's a byte channel node. We use a temporary
+ * variable, 'np2', because we can't release 'np' until we're done with
+ * 'sprop'.
+ */
+ np2 = of_find_node_by_path(sprop);
+ of_node_put(np);
+ np = np2;
+ if (!np) {
+ pr_warning("ehv-bc: stdout node '%s' does not exist\n", sprop);
+ return 0;
+ }
+
+ /* Is it a byte channel? */
+ if (!of_device_is_compatible(np, "epapr,hv-byte-channel")) {
+ of_node_put(np);
+ return 0;
+ }
+
+ stdout_irq = irq_of_parse_and_map(np, 0);
+ if (stdout_irq == NO_IRQ) {
+ pr_err("ehv-bc: no 'interrupts' property in %s node\n", sprop);
+ of_node_put(np);
+ return 0;
+ }
+
+ /*
+ * The 'hv-handle' property contains the handle for this byte channel.
+ */
+ iprop = of_get_property(np, "hv-handle", NULL);
+ if (!iprop) {
+ pr_err("ehv-bc: no 'hv-handle' property in %s node\n",
+ np->name);
+ of_node_put(np);
+ return 0;
+ }
+ stdout_bc = be32_to_cpu(*iprop);
+
+ of_node_put(np);
+ return 1;
+}
+
+/*************************** EARLY CONSOLE DRIVER ***************************/
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_EHV_BC
+
+/*
+ * send a byte to a byte channel, wait if necessary
+ *
+ * This function sends a byte to a byte channel, and it waits and
+ * retries if the byte channel is full. It returns if the character
+ * has been sent, or if some error has occurred.
+ *
+ */
+static void byte_channel_spin_send(const char data)
+{
+ int ret, count;
+
+ do {
+ count = 1;
+ ret = ev_byte_channel_send(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE,
+ &count, &data);
+ } while (ret == EV_EAGAIN);
+}
+
+/*
+ * The udbg subsystem calls this function to display a single character.
+ * We convert CR to a CR/LF.
+ */
+static void ehv_bc_udbg_putc(char c)
+{
+ if (c == '\n')
+ byte_channel_spin_send('\r');
+
+ byte_channel_spin_send(c);
+}
+
+/*
+ * early console initialization
+ *
+ * PowerPC kernels support an early printk console, also known as udbg.
+ * This function must be called via the ppc_md.init_early function pointer.
+ * At this point, the device tree has been unflattened, so we can obtain the
+ * byte channel handle for stdout.
+ *
+ * We only support displaying of characters (putc). We do not support
+ * keyboard input.
+ */
+void __init udbg_init_ehv_bc(void)
+{
+ unsigned int rx_count, tx_count;
+ unsigned int ret;
+
+ /* Check if we're running as a guest of a hypervisor */
+ if (!(mfmsr() & MSR_GS))
+ return;
+
+ /* Verify the byte channel handle */
+ ret = ev_byte_channel_poll(CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE,
+ &rx_count, &tx_count);
+ if (ret)
+ return;
+
+ udbg_putc = ehv_bc_udbg_putc;
+ register_early_udbg_console();
+
+ udbg_printf("ehv-bc: early console using byte channel handle %u\n",
+ CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
+}
+
+#endif
+
+/****************************** CONSOLE DRIVER ******************************/
+
+static struct tty_driver *ehv_bc_driver;
+
+/*
+ * Byte channel console sending worker function.
+ *
+ * For consoles, if the output buffer is full, we should just spin until it
+ * clears.
+ */
+static int ehv_bc_console_byte_channel_send(unsigned int handle, const char *s,
+ unsigned int count)
+{
+ unsigned int len;
+ int ret = 0;
+
+ while (count) {
+ len = min_t(unsigned int, count, EV_BYTE_CHANNEL_MAX_BYTES);
+ do {
+ ret = ev_byte_channel_send(handle, &len, s);
+ } while (ret == EV_EAGAIN);
+ count -= len;
+ s += len;
+ }
+
+ return ret;
+}
+
+/*
+ * write a string to the console
+ *
+ * This function gets called to write a string from the kernel, typically from
+ * a printk(). This function spins until all data is written.
+ *
+ * We copy the data to a temporary buffer because we need to insert a \r in
+ * front of every \n. It's more efficient to copy the data to the buffer than
+ * it is to make multiple hcalls for each character or each newline.
+ */
+static void ehv_bc_console_write(struct console *co, const char *s,
+ unsigned int count)
+{
+ unsigned int handle = (unsigned int)co->data;
+ char s2[EV_BYTE_CHANNEL_MAX_BYTES];
+ unsigned int i, j = 0;
+ char c;
+
+ for (i = 0; i < count; i++) {
+ c = *s++;
+
+ if (c == '\n')
+ s2[j++] = '\r';
+
+ s2[j++] = c;
+ if (j >= (EV_BYTE_CHANNEL_MAX_BYTES - 1)) {
+ if (ehv_bc_console_byte_channel_send(handle, s2, j))
+ return;
+ j = 0;
+ }
+ }
+
+ if (j)
+ ehv_bc_console_byte_channel_send(handle, s2, j);
+}
+
+/*
+ * When /dev/console is opened, the kernel iterates the console list looking
+ * for one with ->device and then calls that method. On success, it expects
+ * the passed-in int* to contain the minor number to use.
+ */
+static struct tty_driver *ehv_bc_console_device(struct console *co, int *index)
+{
+ *index = co->index;
+
+ return ehv_bc_driver;
+}
+
+static struct console ehv_bc_console = {
+ .name = "ttyEHV",
+ .write = ehv_bc_console_write,
+ .device = ehv_bc_console_device,
+ .flags = CON_PRINTBUFFER | CON_ENABLED,
+};
+
+/*
+ * Console initialization
+ *
+ * This is the first function that is called after the device tree is
+ * available, so here is where we determine the byte channel handle and IRQ for
+ * stdout/stdin, even though that information is used by the tty and character
+ * drivers.
+ */
+static int __init ehv_bc_console_init(void)
+{
+ if (!find_console_handle()) {
+ pr_debug("ehv-bc: stdout is not a byte channel\n");
+ return -ENODEV;
+ }
+
+#ifdef CONFIG_PPC_EARLY_DEBUG_EHV_BC
+ /* Print a friendly warning if the user chose the wrong byte channel
+ * handle for udbg.
+ */
+ if (stdout_bc != CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE)
+ pr_warning("ehv-bc: udbg handle %u is not the stdout handle\n",
+ CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
+#endif
+
+ ehv_bc_console.data = (void *)stdout_bc;
+
+ /* add_preferred_console() must be called before register_console(),
+ otherwise it won't work. However, we don't want to enumerate all the
+ byte channels here, either, since we only care about one. */
+
+ add_preferred_console(ehv_bc_console.name, ehv_bc_console.index, NULL);
+ register_console(&ehv_bc_console);
+
+ pr_info("ehv-bc: registered console driver for byte channel %u\n",
+ stdout_bc);
+
+ return 0;
+}
+console_initcall(ehv_bc_console_init);
+
+/******************************** TTY DRIVER ********************************/
+
+/*
+ * byte channel receive interupt handler
+ *
+ * This ISR is called whenever data is available on a byte channel.
+ */
+static irqreturn_t ehv_bc_tty_rx_isr(int irq, void *data)
+{
+ struct ehv_bc_data *bc = data;
+ struct tty_struct *ttys = tty_port_tty_get(&bc->port);
+ unsigned int rx_count, tx_count, len;
+ int count;
+ char buffer[EV_BYTE_CHANNEL_MAX_BYTES];
+ int ret;
+
+ /* ttys could be NULL during a hangup */
+ if (!ttys)
+ return IRQ_HANDLED;
+
+ /* Find out how much data needs to be read, and then ask the TTY layer
+ * if it can handle that much. We want to ensure that every byte we
+ * read from the byte channel will be accepted by the TTY layer.
+ */
+ ev_byte_channel_poll(bc->handle, &rx_count, &tx_count);
+ count = tty_buffer_request_room(ttys, rx_count);
+
+ /* 'count' is the maximum amount of data the TTY layer can accept at
+ * this time. However, during testing, I was never able to get 'count'
+ * to be less than 'rx_count'. I'm not sure whether I'm calling it
+ * correctly.
+ */
+
+ while (count > 0) {
+ len = min_t(unsigned int, count, sizeof(buffer));
+
+ /* Read some data from the byte channel. This function will
+ * never return more than EV_BYTE_CHANNEL_MAX_BYTES bytes.
+ */
+ ev_byte_channel_receive(bc->handle, &len, buffer);
+
+ /* 'len' is now the amount of data that's been received. 'len'
+ * can't be zero, and most likely it's equal to one.
+ */
+
+ /* Pass the received data to the tty layer. */
+ ret = tty_insert_flip_string(ttys, buffer, len);
+
+ /* 'ret' is the number of bytes that the TTY layer accepted.
+ * If it's not equal to 'len', then it means the buffer is
+ * full, which should never happen. If it does happen, we can
+ * exit gracefully, but we drop the last 'len - ret' characters
+ * that we read from the byte channel.
+ */
+ if (ret != len)
+ break;
+
+ count -= len;
+ }
+
+ /* Tell the tty layer that we're done. */
+ tty_flip_buffer_push(ttys);
+
+ tty_kref_put(ttys);
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * dequeue the transmit buffer to the hypervisor
+ *
+ * This function, which can be called in interrupt context, dequeues as much
+ * data as possible from the transmit buffer to the byte channel.
+ */
+static void ehv_bc_tx_dequeue(struct ehv_bc_data *bc)
+{
+ unsigned int count;
+ unsigned int len, ret;
+ unsigned long flags;
+
+ do {
+ spin_lock_irqsave(&bc->lock, flags);
+ len = min_t(unsigned int,
+ CIRC_CNT_TO_END(bc->head, bc->tail, BUF_SIZE),
+ EV_BYTE_CHANNEL_MAX_BYTES);
+
+ ret = ev_byte_channel_send(bc->handle, &len, bc->buf + bc->tail);
+
+ /* 'len' is valid only if the return code is 0 or EV_EAGAIN */
+ if (!ret || (ret == EV_EAGAIN))
+ bc->tail = (bc->tail + len) & (BUF_SIZE - 1);
+
+ count = CIRC_CNT(bc->head, bc->tail, BUF_SIZE);
+ spin_unlock_irqrestore(&bc->lock, flags);
+ } while (count && !ret);
+
+ spin_lock_irqsave(&bc->lock, flags);
+ if (CIRC_CNT(bc->head, bc->tail, BUF_SIZE))
+ /*
+ * If we haven't emptied the buffer, then enable the TX IRQ.
+ * We'll get an interrupt when there's more room in the
+ * hypervisor's output buffer.
+ */
+ enable_tx_interrupt(bc);
+ else
+ disable_tx_interrupt(bc);
+ spin_unlock_irqrestore(&bc->lock, flags);
+}
+
+/*
+ * byte channel transmit interupt handler
+ *
+ * This ISR is called whenever space becomes available for transmitting
+ * characters on a byte channel.
+ */
+static irqreturn_t ehv_bc_tty_tx_isr(int irq, void *data)
+{
+ struct ehv_bc_data *bc = data;
+ struct tty_struct *ttys = tty_port_tty_get(&bc->port);
+
+ ehv_bc_tx_dequeue(bc);
+ if (ttys) {
+ tty_wakeup(ttys);
+ tty_kref_put(ttys);
+ }
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * This function is called when the tty layer has data for us send. We store
+ * the data first in a circular buffer, and then dequeue as much of that data
+ * as possible.
+ *
+ * We don't need to worry about whether there is enough room in the buffer for
+ * all the data. The purpose of ehv_bc_tty_write_room() is to tell the tty
+ * layer how much data it can safely send to us. We guarantee that
+ * ehv_bc_tty_write_room() will never lie, so the tty layer will never send us
+ * too much data.
+ */
+static int ehv_bc_tty_write(struct tty_struct *ttys, const unsigned char *s,
+ int count)
+{
+ struct ehv_bc_data *bc = ttys->driver_data;
+ unsigned long flags;
+ unsigned int len;
+ unsigned int written = 0;
+
+ while (1) {
+ spin_lock_irqsave(&bc->lock, flags);
+ len = CIRC_SPACE_TO_END(bc->head, bc->tail, BUF_SIZE);
+ if (count < len)
+ len = count;
+ if (len) {
+ memcpy(bc->buf + bc->head, s, len);
+ bc->head = (bc->head + len) & (BUF_SIZE - 1);
+ }
+ spin_unlock_irqrestore(&bc->lock, flags);
+ if (!len)
+ break;
+
+ s += len;
+ count -= len;
+ written += len;
+ }
+
+ ehv_bc_tx_dequeue(bc);
+
+ return written;
+}
+
+/*
+ * This function can be called multiple times for a given tty_struct, which is
+ * why we initialize bc->ttys in ehv_bc_tty_port_activate() instead.
+ *
+ * The tty layer will still call this function even if the device was not
+ * registered (i.e. tty_register_device() was not called). This happens
+ * because tty_register_device() is optional and some legacy drivers don't
+ * use it. So we need to check for that.
+ */
+static int ehv_bc_tty_open(struct tty_struct *ttys, struct file *filp)
+{
+ struct ehv_bc_data *bc = &bcs[ttys->index];
+
+ if (!bc->dev)
+ return -ENODEV;
+
+ return tty_port_open(&bc->port, ttys, filp);
+}
+
+/*
+ * Amazingly, if ehv_bc_tty_open() returns an error code, the tty layer will
+ * still call this function to close the tty device. So we can't assume that
+ * the tty port has been initialized.
+ */
+static void ehv_bc_tty_close(struct tty_struct *ttys, struct file *filp)
+{
+ struct ehv_bc_data *bc = &bcs[ttys->index];
+
+ if (bc->dev)
+ tty_port_close(&bc->port, ttys, filp);
+}
+
+/*
+ * Return the amount of space in the output buffer
+ *
+ * This is actually a contract between the driver and the tty layer outlining
+ * how much write room the driver can guarantee will be sent OR BUFFERED. This
+ * driver MUST honor the return value.
+ */
+static int ehv_bc_tty_write_room(struct tty_struct *ttys)
+{
+ struct ehv_bc_data *bc = ttys->driver_data;
+ unsigned long flags;
+ int count;
+
+ spin_lock_irqsave(&bc->lock, flags);
+ count = CIRC_SPACE(bc->head, bc->tail, BUF_SIZE);
+ spin_unlock_irqrestore(&bc->lock, flags);
+
+ return count;
+}
+
+/*
+ * Stop sending data to the tty layer
+ *
+ * This function is called when the tty layer's input buffers are getting full,
+ * so the driver should stop sending it data. The easiest way to do this is to
+ * disable the RX IRQ, which will prevent ehv_bc_tty_rx_isr() from being
+ * called.
+ *
+ * The hypervisor will continue to queue up any incoming data. If there is any
+ * data in the queue when the RX interrupt is enabled, we'll immediately get an
+ * RX interrupt.
+ */
+static void ehv_bc_tty_throttle(struct tty_struct *ttys)
+{
+ struct ehv_bc_data *bc = ttys->driver_data;
+
+ disable_irq(bc->rx_irq);
+}
+
+/*
+ * Resume sending data to the tty layer
+ *
+ * This function is called after previously calling ehv_bc_tty_throttle(). The
+ * tty layer's input buffers now have more room, so the driver can resume
+ * sending it data.
+ */
+static void ehv_bc_tty_unthrottle(struct tty_struct *ttys)
+{
+ struct ehv_bc_data *bc = ttys->driver_data;
+
+ /* If there is any data in the queue when the RX interrupt is enabled,
+ * we'll immediately get an RX interrupt.
+ */
+ enable_irq(bc->rx_irq);
+}
+
+static void ehv_bc_tty_hangup(struct tty_struct *ttys)
+{
+ struct ehv_bc_data *bc = ttys->driver_data;
+
+ ehv_bc_tx_dequeue(bc);
+ tty_port_hangup(&bc->port);
+}
+
+/*
+ * TTY driver operations
+ *
+ * If we could ask the hypervisor how much data is still in the TX buffer, or
+ * at least how big the TX buffers are, then we could implement the
+ * .wait_until_sent and .chars_in_buffer functions.
+ */
+static const struct tty_operations ehv_bc_ops = {
+ .open = ehv_bc_tty_open,
+ .close = ehv_bc_tty_close,
+ .write = ehv_bc_tty_write,
+ .write_room = ehv_bc_tty_write_room,
+ .throttle = ehv_bc_tty_throttle,
+ .unthrottle = ehv_bc_tty_unthrottle,
+ .hangup = ehv_bc_tty_hangup,
+};
+
+/*
+ * initialize the TTY port
+ *
+ * This function will only be called once, no matter how many times
+ * ehv_bc_tty_open() is called. That's why we register the ISR here, and also
+ * why we initialize tty_struct-related variables here.
+ */
+static int ehv_bc_tty_port_activate(struct tty_port *port,
+ struct tty_struct *ttys)
+{
+ struct ehv_bc_data *bc = container_of(port, struct ehv_bc_data, port);
+ int ret;
+
+ ttys->driver_data = bc;
+
+ ret = request_irq(bc->rx_irq, ehv_bc_tty_rx_isr, 0, "ehv-bc", bc);
+ if (ret < 0) {
+ dev_err(bc->dev, "could not request rx irq %u (ret=%i)\n",
+ bc->rx_irq, ret);
+ return ret;
+ }
+
+ /* request_irq also enables the IRQ */
+ bc->tx_irq_enabled = 1;
+
+ ret = request_irq(bc->tx_irq, ehv_bc_tty_tx_isr, 0, "ehv-bc", bc);
+ if (ret < 0) {
+ dev_err(bc->dev, "could not request tx irq %u (ret=%i)\n",
+ bc->tx_irq, ret);
+ free_irq(bc->rx_irq, bc);
+ return ret;
+ }
+
+ /* The TX IRQ is enabled only when we can't write all the data to the
+ * byte channel at once, so by default it's disabled.
+ */
+ disable_tx_interrupt(bc);
+
+ return 0;
+}
+
+static void ehv_bc_tty_port_shutdown(struct tty_port *port)
+{
+ struct ehv_bc_data *bc = container_of(port, struct ehv_bc_data, port);
+
+ free_irq(bc->tx_irq, bc);
+ free_irq(bc->rx_irq, bc);
+}
+
+static const struct tty_port_operations ehv_bc_tty_port_ops = {
+ .activate = ehv_bc_tty_port_activate,
+ .shutdown = ehv_bc_tty_port_shutdown,
+};
+
+static int __devinit ehv_bc_tty_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct ehv_bc_data *bc;
+ const uint32_t *iprop;
+ unsigned int handle;
+ int ret;
+ static unsigned int index = 1;
+ unsigned int i;
+
+ iprop = of_get_property(np, "hv-handle", NULL);
+ if (!iprop) {
+ dev_err(&pdev->dev, "no 'hv-handle' property in %s node\n",
+ np->name);
+ return -ENODEV;
+ }
+
+ /* We already told the console layer that the index for the console
+ * device is zero, so we need to make sure that we use that index when
+ * we probe the console byte channel node.
+ */
+ handle = be32_to_cpu(*iprop);
+ i = (handle == stdout_bc) ? 0 : index++;
+ bc = &bcs[i];
+
+ bc->handle = handle;
+ bc->head = 0;
+ bc->tail = 0;
+ spin_lock_init(&bc->lock);
+
+ bc->rx_irq = irq_of_parse_and_map(np, 0);
+ bc->tx_irq = irq_of_parse_and_map(np, 1);
+ if ((bc->rx_irq == NO_IRQ) || (bc->tx_irq == NO_IRQ)) {
+ dev_err(&pdev->dev, "no 'interrupts' property in %s node\n",
+ np->name);
+ ret = -ENODEV;
+ goto error;
+ }
+
+ bc->dev = tty_register_device(ehv_bc_driver, i, &pdev->dev);
+ if (IS_ERR(bc->dev)) {
+ ret = PTR_ERR(bc->dev);
+ dev_err(&pdev->dev, "could not register tty (ret=%i)\n", ret);
+ goto error;
+ }
+
+ tty_port_init(&bc->port);
+ bc->port.ops = &ehv_bc_tty_port_ops;
+
+ dev_set_drvdata(&pdev->dev, bc);
+
+ dev_info(&pdev->dev, "registered /dev/%s%u for byte channel %u\n",
+ ehv_bc_driver->name, i, bc->handle);
+
+ return 0;
+
+error:
+ irq_dispose_mapping(bc->tx_irq);
+ irq_dispose_mapping(bc->rx_irq);
+
+ memset(bc, 0, sizeof(struct ehv_bc_data));
+ return ret;
+}
+
+static int ehv_bc_tty_remove(struct platform_device *pdev)
+{
+ struct ehv_bc_data *bc = dev_get_drvdata(&pdev->dev);
+
+ tty_unregister_device(ehv_bc_driver, bc - bcs);
+
+ irq_dispose_mapping(bc->tx_irq);
+ irq_dispose_mapping(bc->rx_irq);
+
+ return 0;
+}
+
+static const struct of_device_id ehv_bc_tty_of_ids[] = {
+ { .compatible = "epapr,hv-byte-channel" },
+ {}
+};
+
+static struct platform_driver ehv_bc_tty_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "ehv-bc",
+ .of_match_table = ehv_bc_tty_of_ids,
+ },
+ .probe = ehv_bc_tty_probe,
+ .remove = ehv_bc_tty_remove,
+};
+
+/**
+ * ehv_bc_init - ePAPR hypervisor byte channel driver initialization
+ *
+ * This function is called when this module is loaded.
+ */
+static int __init ehv_bc_init(void)
+{
+ struct device_node *np;
+ unsigned int count = 0; /* Number of elements in bcs[] */
+ int ret;
+
+ pr_info("ePAPR hypervisor byte channel driver\n");
+
+ /* Count the number of byte channels */
+ for_each_compatible_node(np, NULL, "epapr,hv-byte-channel")
+ count++;
+
+ if (!count)
+ return -ENODEV;
+
+ /* The array index of an element in bcs[] is the same as the tty index
+ * for that element. If you know the address of an element in the
+ * array, then you can use pointer math (e.g. "bc - bcs") to get its
+ * tty index.
+ */
+ bcs = kzalloc(count * sizeof(struct ehv_bc_data), GFP_KERNEL);
+ if (!bcs)
+ return -ENOMEM;
+
+ ehv_bc_driver = alloc_tty_driver(count);
+ if (!ehv_bc_driver) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ ehv_bc_driver->owner = THIS_MODULE;
+ ehv_bc_driver->driver_name = "ehv-bc";
+ ehv_bc_driver->name = ehv_bc_console.name;
+ ehv_bc_driver->type = TTY_DRIVER_TYPE_CONSOLE;
+ ehv_bc_driver->subtype = SYSTEM_TYPE_CONSOLE;
+ ehv_bc_driver->init_termios = tty_std_termios;
+ ehv_bc_driver->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ tty_set_operations(ehv_bc_driver, &ehv_bc_ops);
+
+ ret = tty_register_driver(ehv_bc_driver);
+ if (ret) {
+ pr_err("ehv-bc: could not register tty driver (ret=%i)\n", ret);
+ goto error;
+ }
+
+ ret = platform_driver_register(&ehv_bc_tty_driver);
+ if (ret) {
+ pr_err("ehv-bc: could not register platform driver (ret=%i)\n",
+ ret);
+ goto error;
+ }
+
+ return 0;
+
+error:
+ if (ehv_bc_driver) {
+ tty_unregister_driver(ehv_bc_driver);
+ put_tty_driver(ehv_bc_driver);
+ }
+
+ kfree(bcs);
+
+ return ret;
+}
+
+
+/**
+ * ehv_bc_exit - ePAPR hypervisor byte channel driver termination
+ *
+ * This function is called when this driver is unloaded.
+ */
+static void __exit ehv_bc_exit(void)
+{
+ tty_unregister_driver(ehv_bc_driver);
+ put_tty_driver(ehv_bc_driver);
+ kfree(bcs);
+}
+
+module_init(ehv_bc_init);
+module_exit(ehv_bc_exit);
+
+MODULE_AUTHOR("Timur Tabi <timur@freescale.com>");
+MODULE_DESCRIPTION("ePAPR hypervisor byte channel driver");
+MODULE_LICENSE("GPL v2");
--
1.7.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox