* Re: linux-next: manual merge of the moduleh tree with the arm tree
From: Paul Gortmaker @ 2011-08-25 22:40 UTC (permalink / raw)
To: Russell King; +Cc: Stephen Rothwell, linux-next, linux-kernel, Jon Medhurst
In-Reply-To: <20110825163901.GA467@flint.arm.linux.org.uk>
On 11-08-25 12:39 PM, Russell King wrote:
> On Thu, Aug 25, 2011 at 12:33:51PM -0400, Paul Gortmaker wrote:
>> On 11-08-25 01:17 AM, Stephen Rothwell wrote:
>>> 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.
>>
>> I can't really relocate the page.h inclusion in a trivial way to
>> make this conflict go away. But since the implicit header use fixes
>> for arm are independent and don't actually depend on anything in the
>> rest of the module.h tree, I can set about to giving these to Russell
>> for his arm-next branch anytime. I'll do that shortly.
>
> For such a trivial conflict, I don't think we need to do anything. Linus
> has said publically that he likes to sort out conflicts as it allows him
> to have a wider knowledge of what's going on in the kernel tree.
>
> So, given that the fixup is soo obvious, I don't think we need to play
> games redistributing patches - we just need to be aware of the conflict
> and mention it to Linus when we merge.
OK. I was entertaining feeding some of the really obvious and simple
parts of the moduleh branch out to the various maintainers just to
reduce its overall size, but in the end I guess that just makes work
for me and them -- vs. a single pull request to Linus for addition to
v3.2-rc1. I'll just stay the course and Stephen will have to rerere
the merge conflict resolution for a while -- something I'm certain
that he has automated long long ago.
Thanks,
Paul.
^ permalink raw reply
* Re: [Patch] numa: introduce CONFIG_NUMA_SYSFS for drivers/base/node.c
From: David Rientjes @ 2011-08-25 20:57 UTC (permalink / raw)
To: Cong Wang
Cc: Randy Dunlap, Andrew Morton, Stephen Rothwell, gregkh, linux-next,
LKML, linux-mm
In-Reply-To: <4E562248.2090102@redhat.com>
On Thu, 25 Aug 2011, Cong Wang wrote:
> > 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?
>
node_states[], which is revealed at link time if you tried to compile your
patch. It's obvious that we don't want to add per-node hugetlbfs
attributes to sysfs directories if sysfs is disabled, so you need to
modify the hugetlbfs code as well.
--
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: Andrew Morton @ 2011-08-25 19:23 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, linux-mm, linux-fsdevel, linux-next
In-Reply-To: <20110825135103.GA6431@tiehlicka.suse.cz>
On Thu, 25 Aug 2011 15:51:03 +0200
Michal Hocko <mhocko@suse.cz> 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.
Parenthetically, there's not much point in running -mm any more:
everything which matters is copied into linux-next, so just run the
following day's -next.
There are a few things in -mm which aren't transferrrred to -next. Some
akpm-specific pain reducers, a few patches which don't look like
they'll ever get into mainline and a great shower of debugging patches
which I accumulated over the ages.
--
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] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Greg KH @ 2011-08-25 19:03 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <4E5699A8.1070708@freescale.com>
On Thu, Aug 25, 2011 at 01:51:20PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > But don't you really want this type of check at runtime? What happens
> > if you load this driver on a machine that is not a guest? Will things
> > break? Shouldn't you still refuse to load somehow?
>
> This is in the udbg code, which falls under the category of, "turn this on only
> if you know what you're doing."
>
> The udbg code runs very early, before the device tree is available. There's no
> way of knowing at this point whether or not we're running under a hypervisor.
> If you turn on udbg support, then it means that you're trying to do some very
> specific debugging on a specific platform.
>
> So I'm not removing this code just to fix the build break. It really should
> never have been there in the first place.
Ok, thanks for the details, I'll queue up the patch in a bit.
greg k-h
^ permalink raw reply
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:51 UTC (permalink / raw)
To: Greg KH; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20110825184655.GB1891@kroah.com>
Greg KH wrote:
> But don't you really want this type of check at runtime? What happens
> if you load this driver on a machine that is not a guest? Will things
> break? Shouldn't you still refuse to load somehow?
This is in the udbg code, which falls under the category of, "turn this on only
if you know what you're doing."
The udbg code runs very early, before the device tree is available. There's no
way of knowing at this point whether or not we're running under a hypervisor.
If you turn on udbg support, then it means that you're trying to do some very
specific debugging on a specific platform.
So I'm not removing this code just to fix the build break. It really should
never have been there in the first place.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Greg KH @ 2011-08-25 18:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <4E568E19.405@freescale.com>
On Thu, Aug 25, 2011 at 01:02:01PM -0500, Timur Tabi wrote:
> Greg KH wrote:
> > tested doesn't mean that it shouldn't still build properly for other
> > platforms, right?
>
> The problem is the dependency on MSR_GS, which is defined only for Book-E
> PowerPC chips, not all PowerPC.
>
> So I gave it some more thought, and technically ePAPR extends beyond Book-E, so
> it's wrong for the driver to depend on anything specific to Book-E. I've
> removed the code that breaks:
>
> /* Check if we're running as a guest of a hypervisor */
> if (!(mfmsr() & MSR_GS))
> return;
But don't you really want this type of check at runtime? What happens
if you load this driver on a machine that is not a guest? Will things
break? Shouldn't you still refuse to load somehow?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: H. Peter Anvin @ 2011-08-25 18:26 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Stephen Rothwell, Xen Devel, Peter Zijlstra, linux-kernel,
linux-next, Thomas Gleixner, Ingo Molnar
In-Reply-To: <4E5690C3.2050706@goop.org>
On 08/25/2011 11:13 AM, Jeremy Fitzhardinge wrote:
> On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the xen tree got a conflict in
>> arch/x86/include/asm/spinlock.h between a series of commits from the tip
>> tree and a smaller series of similar commits from the xen tree.
>>
>> I see that Linus is commenting on these patches at the moment, and its
>> not easy to resolve the conflicts, so I will just use the xen tree from
>> next-20110824 for today.
>>
>
> Thanks Stephen; the xen tree ones are more current, and I want to make
> sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
>
Stephen: the x86/spinlocks branch in the -tip tree is obsolete and
should be dropped.
-hpa
^ permalink raw reply
* Re: linux-next: manual merge of the xen tree with the tip tree
From: Jeremy Fitzhardinge @ 2011-08-25 18:13 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Xen Devel, linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
In-Reply-To: <20110825142450.c84e02d8763cfd1a93411844@canb.auug.org.au>
On 08/24/2011 09:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xen tree got a conflict in
> arch/x86/include/asm/spinlock.h between a series of commits from the tip
> tree and a smaller series of similar commits from the xen tree.
>
> I see that Linus is commenting on these patches at the moment, and its
> not easy to resolve the conflicts, so I will just use the xen tree from
> next-20110824 for today.
>
Thanks Stephen; the xen tree ones are more current, and I want to make
sure I didn't screw up any of the cmpxchg/xadd changes in a wider test env.
J
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (akpm and moduleh trees related)
From: Paul Gortmaker @ 2011-08-25 18:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Andrew Morton, linux-next, linux-kernel, Yanmin Zhang
In-Reply-To: <20110825161750.45803be66cba17a6bd3906bc@canb.auug.org.au>
On 11-08-25 02:17 AM, Stephen Rothwell wrote:
> 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.
Thanks Stephen, I've excluded kernel/printk.c from the conversion to
export.h today.
Paul.
>
> P.S. Andrew, these commits could do with better subject lines :-(
^ permalink raw reply
* [PATCH] [v2] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:06 UTC (permalink / raw)
To: greg, sfr, linux-next, linux-kernel, linuxppc-dev
The ePAPR hypervisor byte channel driver is supposed to work on all
ePAPR-compliant embedded PowerPC systems, but it had a reference to the MSR_GS
bit, which is available only on Book-E systems.
Also fix a couple integer-to-pointer typecast problems.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/tty/ehv_bytechan.c | 8 ++------
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/ehv_bytechan.c b/drivers/tty/ehv_bytechan.c
index e67f70b..f733718 100644
--- a/drivers/tty/ehv_bytechan.c
+++ b/drivers/tty/ehv_bytechan.c
@@ -226,10 +226,6 @@ 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);
@@ -286,7 +282,7 @@ static int ehv_bc_console_byte_channel_send(unsigned int handle, const char *s,
static void ehv_bc_console_write(struct console *co, const char *s,
unsigned int count)
{
- unsigned int handle = (unsigned int)co->data;
+ unsigned int handle = (uintptr_t)co->data;
char s2[EV_BYTE_CHANNEL_MAX_BYTES];
unsigned int i, j = 0;
char c;
@@ -352,7 +348,7 @@ static int __init ehv_bc_console_init(void)
CONFIG_PPC_EARLY_DEBUG_EHV_BC_HANDLE);
#endif
- ehv_bc_console.data = (void *)stdout_bc;
+ ehv_bc_console.data = (void *)(uintptr_t)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
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 18:02 UTC (permalink / raw)
To: Greg KH; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20110825163234.GA31629@kroah.com>
Greg KH wrote:
> tested doesn't mean that it shouldn't still build properly for other
> platforms, right?
The problem is the dependency on MSR_GS, which is defined only for Book-E
PowerPC chips, not all PowerPC.
So I gave it some more thought, and technically ePAPR extends beyond Book-E, so
it's wrong for the driver to depend on anything specific to Book-E. I've
removed the code that breaks:
/* Check if we're running as a guest of a hypervisor */
if (!(mfmsr() & MSR_GS))
return;
> What is keeping the driver from building on all PPC, or even all arches
> today?
I've made a few changes, and it builds on all PPC now. I'll post a new patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [patch] numa: fix NUMA compile error when sysfs and procfs are disabled
From: Randy Dunlap @ 2011-08-25 17:17 UTC (permalink / raw)
To: David Rientjes
Cc: Andrew Morton, Cong Wang, Stephen Rothwell, Greg Kroah-Hartman,
linux-next, LKML, linux-mm
In-Reply-To: <alpine.DEB.2.00.1108242224180.576@chino.kir.corp.google.com>
On Wed, 24 Aug 2011 22:55:02 -0700 (PDT) David Rientjes wrote:
> 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>
Sure, that also works.
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
> ---
> 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
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: mmotm 2011-08-24-14-08 uploaded
From: Randy Dunlap @ 2011-08-25 17:12 UTC (permalink / raw)
To: Johannes Weiner, quilt-dev
Cc: Stephen Rothwell, Michal Hocko, akpm, mm-commits, linux-kernel,
linux-mm, linux-fsdevel, linux-next
In-Reply-To: <20110825154538.GA5860@redhat.com>
On Thu, 25 Aug 2011 17:45:38 +0200 Johannes Weiner wrote:
> On Fri, Aug 26, 2011 at 01:09:38AM +1000, Stephen Rothwell wrote:
> > 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.
>
> You can probably replace `patch' in your $PATH by a wrapper that uses
> git-apply, which can deal with them.
>
> Or you could use git-quiltimport, which uses git-apply, to prepare the
> -mmotm base tree in git, on top of which you can continue to work with
> quilt.
>
> I do this with a cron-job automatically, you can find the result here:
>
> http://git.kernel.org/?p=linux/kernel/git/hannes/linux-mmotm.git;a=summary
>
> If you want to do it manually, there is sometimes confusing binary
> file patch sections in -mmotm, which in turn git-apply can not deal
> with, so I use the following uncrapdiff.awk filter on the patches
> before import.
I thought that I recently saw a reference to an unreleased version of quilt
that handles git symlinks. Was I dreaming?
or where is it?
Thanks.
> ---
>
> # Filter out sections that feature an index line but
> # no real diff part that would start with '--- file'
>
> {
> if (HEADER ~ /^diff --git /) {
> if ($0 ~ /^index /) {
> INDEX=$0
> } else if ($0 ~ /^diff --git /) {
> print(HEADER)
> HEADER=$0
> } else if (INDEX ~ /^index /) {
> if ($0 ~ /^--- /) {
> print(HEADER)
> print(INDEX)
> print($0)
> }
> HEADER=""
> INDEX=""
> } else {
> HEADER=HEADER "\n" $0
> }
> } else if ($0 ~ /^diff --git /) {
> HEADER=$0
> } else {
> print($0)
> }
> }
>
> ---
---
~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: manual merge of the moduleh tree with the arm tree
From: Russell King @ 2011-08-25 16:39 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Stephen Rothwell, linux-next, linux-kernel, Jon Medhurst
In-Reply-To: <4E56796F.8090703@windriver.com>
On Thu, Aug 25, 2011 at 12:33:51PM -0400, Paul Gortmaker wrote:
> On 11-08-25 01:17 AM, Stephen Rothwell wrote:
> > 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.
>
> I can't really relocate the page.h inclusion in a trivial way to
> make this conflict go away. But since the implicit header use fixes
> for arm are independent and don't actually depend on anything in the
> rest of the module.h tree, I can set about to giving these to Russell
> for his arm-next branch anytime. I'll do that shortly.
For such a trivial conflict, I don't think we need to do anything. Linus
has said publically that he likes to sort out conflicts as it allows him
to have a wider knowledge of what's going on in the kernel tree.
So, given that the fixup is soo obvious, I don't think we need to play
games redistributing patches - we just need to be aware of the conflict
and mention it to Linus when we merge.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: linux-next: manual merge of the moduleh tree with the arm tree
From: Paul Gortmaker @ 2011-08-25 16:33 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Jon Medhurst, Russell King
In-Reply-To: <20110825151748.8e41e0ded739187a1432cf0b@canb.auug.org.au>
On 11-08-25 01:17 AM, Stephen Rothwell wrote:
> 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.
I can't really relocate the page.h inclusion in a trivial way to
make this conflict go away. But since the implicit header use fixes
for arm are independent and don't actually depend on anything in the
rest of the module.h tree, I can set about to giving these to Russell
for his arm-next branch anytime. I'll do that shortly.
Thanks,
Paul.
>
> Jst context changes I fixed it up (see below) and can carry the fix as
> necessary.
^ permalink raw reply
* Re: [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Greg KH @ 2011-08-25 16:32 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <1314289245-14946-1-git-send-email-timur@freescale.com>
On Thu, Aug 25, 2011 at 11:20:45AM -0500, Timur Tabi wrote:
> The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on PPC",
> which means it would compile on all PowerPC platforms, even though it's
> only been tested on Freescale platforms. Change the Kconfig to depend on
> FSL_SOC instead.
tested doesn't mean that it shouldn't still build properly for other
platforms, right?
What is keeping the driver from building on all PPC, or even all arches
today?
greg k-h
^ permalink raw reply
* [PATCH] tty/powerpc: fix build break with ehv_bytechan.c on allyesconfig
From: Timur Tabi @ 2011-08-25 16:20 UTC (permalink / raw)
To: greg, sfr, linux-next, linux-kernel, linuxppc-dev
The Kconfig for the ePAPR hypervisor byte channel driver has a "depends on PPC",
which means it would compile on all PowerPC platforms, even though it's
only been tested on Freescale platforms. Change the Kconfig to depend on
FSL_SOC instead.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index f1ea59b..535af0a 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -353,7 +353,7 @@ config TRACE_SINK
config PPC_EPAPR_HV_BYTECHAN
tristate "ePAPR hypervisor byte channel driver"
- depends on PPC
+ depends on FSL_SOC
help
This driver creates /dev entries for each ePAPR hypervisor byte
channel, thereby allowing applications to communicate with byte
--
1.7.3.4
^ permalink raw reply related
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Arnaud Lacombe @ 2011-08-25 16:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Timur Tabi, Greg KH, linux-next, linux-kernel, ppc-dev
In-Reply-To: <20110826015111.49af16f792d5554fd931d230@canb.auug.org.au>
Hi,
On Thu, Aug 25, 2011 at 11:51 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Timur,
>
> On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi <timur@freescale.com> wrote:
>>
>> 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.
>
> We get lots of those in many builds. :-( Just a warning.
>
If you could provide an exhaustive list of them, I'd be interested. Do
you account/reference them in the report you make on each new -next
tree ?
- Arnaud
>> 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
>
> There is a patch for that pending with either the kvm guys or the powerpc guys.
>
>> I guess I don't have the right compiler.
>
> Yours seems to be OK. If you pass -k to make it will get further. Or
> you could configure it and then just try building your driver rather than
> the whole tree.
>
>> Anyway, I think I know how to fix the break that Stephen is seeing. I will post
>> a v4 patch in a few minutes.
>
> Thanks.
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
>
^ permalink raw reply
* Re: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
From: Timur Tabi @ 2011-08-25 16:03 UTC (permalink / raw)
To: Greg KH; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <20110825155050.GA10084@kroah.com>
Greg KH wrote:
> No, this doesn't work, I need just a fix, as I took your previous patch
> already.
Sorry, coming right up.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] [v4] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver
From: Greg KH @ 2011-08-25 15:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: sfr, linux-next, linux-kernel, linuxppc-dev
In-Reply-To: <1314286345-27056-1-git-send-email-timur@freescale.com>
On Thu, Aug 25, 2011 at 10:32:25AM -0500, Timur Tabi wrote:
> 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>
No, this doesn't work, I need just a fix, as I took your previous patch
already.
greg k-h
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (tty tree related)
From: Stephen Rothwell @ 2011-08-25 15:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: Greg KH, linux-next, linux-kernel, ppc-dev
In-Reply-To: <4E56689D.3080202@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
Hi Timur,
On Thu, 25 Aug 2011 10:22:05 -0500 Timur Tabi <timur@freescale.com> wrote:
>
> 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.
We get lots of those in many builds. :-( Just a warning.
> 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
There is a patch for that pending with either the kvm guys or the powerpc guys.
> I guess I don't have the right compiler.
Yours seems to be OK. If you pass -k to make it will get further. Or
you could configure it and then just try building your driver rather than
the whole tree.
> Anyway, I think I know how to fix the break that Stephen is seeing. I will post
> a v4 patch in a few minutes.
Thanks.
--
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
* Re: mmotm 2011-08-24-14-08 uploaded
From: Johannes Weiner @ 2011-08-25 15:45 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Hocko, akpm, mm-commits, linux-kernel, linux-mm,
linux-fsdevel, linux-next
In-Reply-To: <20110826010938.5795e43137d58c9f42d44458@canb.auug.org.au>
On Fri, Aug 26, 2011 at 01:09:38AM +1000, Stephen Rothwell wrote:
> 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.
You can probably replace `patch' in your $PATH by a wrapper that uses
git-apply, which can deal with them.
Or you could use git-quiltimport, which uses git-apply, to prepare the
-mmotm base tree in git, on top of which you can continue to work with
quilt.
I do this with a cron-job automatically, you can find the result here:
http://git.kernel.org/?p=linux/kernel/git/hannes/linux-mmotm.git;a=summary
If you want to do it manually, there is sometimes confusing binary
file patch sections in -mmotm, which in turn git-apply can not deal
with, so I use the following uncrapdiff.awk filter on the patches
before import.
---
# Filter out sections that feature an index line but
# no real diff part that would start with '--- file'
{
if (HEADER ~ /^diff --git /) {
if ($0 ~ /^index /) {
INDEX=$0
} else if ($0 ~ /^diff --git /) {
print(HEADER)
HEADER=$0
} else if (INDEX ~ /^index /) {
if ($0 ~ /^--- /) {
print(HEADER)
print(INDEX)
print($0)
}
HEADER=""
INDEX=""
} else {
HEADER=HEADER "\n" $0
}
} else if ($0 ~ /^diff --git /) {
HEADER=$0
} else {
print($0)
}
}
---
HTH
--
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 staging tree
From: Greg KH @ 2011-08-25 15:39 UTC (permalink / raw)
To: Larry Finger
Cc: Stephen Rothwell, linux-next, linux-kernel, wlanfae, Jiri Pirko,
David Miller, netdev
In-Reply-To: <4E55DA8C.10102@lwfinger.net>
On Thu, Aug 25, 2011 at 12:15:56AM -0500, Larry Finger wrote:
> 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.
It wouldn't ever make it there, as that's coming from the net-next tree,
so this will have to wait until stuff merges together in Linus's tree.
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the usb tree with the usb.current tree
From: Greg KH @ 2011-08-25 15:39 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Kuninori Morimoto, Sarah Sharp
In-Reply-To: <20110825145206.4888b9f62a9bcbeeaf8678b8@canb.auug.org.au>
On Thu, Aug 25, 2011 at 02:52:06PM +1000, Stephen Rothwell wrote:
> 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.
Thanks, when I get the usb.current tree merged with Linus, I'll handle
this merge in the usb.next tree.
greg k-h
^ 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