* Re: the printk problem
From: Matthew Wilcox @ 2008-07-04 20:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ia64, linuxppc-dev, Peter Anvin, Andrew Morton,
David S. Miller, parisc-linux
In-Reply-To: <alpine.LFD.1.10.0807041250220.2815@woody.linux-foundation.org>
On Fri, Jul 04, 2008 at 01:02:05PM -0700, Linus Torvalds wrote:
> On Fri, 4 Jul 2008, Linus Torvalds wrote:
> >
> > so I think we could easily just say that we extend %p in various ways:
> >
> > - %pS - print pointer as a symbol
> >
> > and leave tons of room for future extensions for different kinds of
> > pointers.
>
> So here's a totally untested example patch of this, which could probably
> easily be extended to to other things.
>
> I actually made it '%pF' and '%pS' for a Function descriptor pointer and
> normal Symbolic pointer respectively, because of the stupid things ia64
> and PPC64 do with the pointer indirection through function descriptors.
It's also true for parisc, fwiw. Added a cc to them.
> That function descriptor indirection is totally untested, and I did it
> with a
>
> pagefault_disable();
> __get_user(..)
> pagefault_enable();
>
> thing because I thought it would be nice if printk() was always safe, and
> passing bogus function pointers to '%pF' should try to work, but quite
> frankly, I didn't even check that that part compiles, much less works.
>
> ia64/ppc lists cc'd, just in case somebody wants to test this.
>
> NOTE! There are no current actual users of this, but the _idea_ is that we
> should be able to just do
>
> printk("%pF\n", desc->handle_irq);
>
> instead of using
>
> print_symbol("%s\n", (unsigned long)desc->handle_irq);
>
> The latter is from kernel/irq/internals.h, and actually looks incorrect -
> shouldn't it use print_fn_descriptor_symbol(), since it's a C level
> function pointer? We should use "print_symbol()" for return pointers we
> find on the stack and data pointers, but not for stuff that actually has a
> C type that is a function pointer?
>
> Somebody who cares about the insane function descriptors should take a
> deeper look.
>
> NOTE AGAIN! UNTESTED! I could easily have screwed up printk() _entirely_,
> since I had to factor out the string handling into a function of its own.
>
> Linus
> ---
> lib/vsprintf.c | 102 ++++++++++++++++++++++++++++++++++++++++---------------
> 1 files changed, 74 insertions(+), 28 deletions(-)
>
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 6021757..148b656 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -22,6 +22,7 @@
> #include <linux/string.h>
> #include <linux/ctype.h>
> #include <linux/kernel.h>
> +#include <linux/kallsyms.h>
>
> #include <asm/page.h> /* for PAGE_SIZE */
> #include <asm/div64.h>
> @@ -482,6 +483,72 @@ static char *number(char *buf, char *end, unsigned long long num, int base, int
> return buf;
> }
>
> +static char *string(char *buf, char *end, char *s, int field_width, int precision, int flags)
> +{
> + int len, i;
> +
> + if ((unsigned long)s < PAGE_SIZE)
> + s = "<NULL>";
> +
> + len = strnlen(s, precision);
> +
> + if (!(flags & LEFT)) {
> + while (len < field_width--) {
> + if (buf < end)
> + *buf = ' ';
> + ++buf;
> + }
> + }
> + for (i = 0; i < len; ++i) {
> + if (buf < end)
> + *buf = *s;
> + ++buf; ++s;
> + }
> + while (len < field_width--) {
> + if (buf < end)
> + *buf = ' ';
> + ++buf;
> + }
> + return buf;
> +}
> +
> +/*
> + * Show a '%p' thing. A kernel extension is that the '%p' is followed
> + * by an extra set of alphanumeric characters that are extended format
> + * specifiers. Right now we just handle 'F' (for symbolic Function
> + * pointers) and 'S' (for Symbolic data pointers), but this can easily
> + * be extended in the future (network address types etc).
> + *
> + * The difference between 'S' and 'F' is that on ia64 and ppc64 function
> + * pointers are really function descriptors, which contain a pointer the
> + * real address.
> + */
> +static char *pointer(const char *fmt, char *buf, char *end, void *ptr, int base, int size, int precision, int type)
> +{
> + char sym[KSYM_SYMBOL_LEN];
> + switch (*fmt) {
> + case 'F': /* Function pointer */
> +#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
> + { void *p;
> + pagefault_disable();
> + if (!__get_user((void **)ptr, &p))
> + ptr = p;
> + pagefault_enable();
> + }
> +#endif
> + /* Fallthrough */
> + case 'S': /* Other pointer */
> +#if CONFIG_KALLSYMS
> + sprint_symbol(sym, (unsigned long) ptr);
> + return string(buf, end, sym, size, precision, type);
> +#else
> + type |= SPECIAL;
> + break;
> +#endif
> + }
> + return number(buf, end, (unsigned long long) ptr, base, size, precision, type);
> +}
> +
> /**
> * vsnprintf - Format a string and place it in a buffer
> * @buf: The buffer to place the result into
> @@ -502,11 +569,9 @@ static char *number(char *buf, char *end, unsigned long long num, int base, int
> */
> int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> {
> - int len;
> unsigned long long num;
> - int i, base;
> + int base;
> char *str, *end, c;
> - const char *s;
>
> int flags; /* flags to number() */
>
> @@ -622,29 +687,7 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> continue;
>
> case 's':
> - s = va_arg(args, char *);
> - if ((unsigned long)s < PAGE_SIZE)
> - s = "<NULL>";
> -
> - len = strnlen(s, precision);
> -
> - if (!(flags & LEFT)) {
> - while (len < field_width--) {
> - if (str < end)
> - *str = ' ';
> - ++str;
> - }
> - }
> - for (i = 0; i < len; ++i) {
> - if (str < end)
> - *str = *s;
> - ++str; ++s;
> - }
> - while (len < field_width--) {
> - if (str < end)
> - *str = ' ';
> - ++str;
> - }
> + str = string(str, end, va_arg(args, char *), field_width, precision, flags);
> continue;
>
> case 'p':
> @@ -653,9 +696,12 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
> field_width = 2*sizeof(void *);
> flags |= ZEROPAD;
> }
> - str = number(str, end,
> - (unsigned long) va_arg(args, void *),
> + str = pointer(fmt+1, str, end,
> + va_arg(args, void *),
> 16, field_width, precision, flags);
> + /* Skip all alphanumeric pointer suffixes */
> + while (isalnum(fmt[1]))
> + fmt++;
> continue;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: the printk problem
From: Linus Torvalds @ 2008-07-04 20:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-ia64, David S. Miller, Peter Anvin
In-Reply-To: <20080704132716.f1e12554.akpm@linux-foundation.org>
On Fri, 4 Jul 2008, Andrew Morton wrote:
>
> probe_kernel_address() should be usable here.
Right you are.
> > +static char *string(char *buf, char *end, char *s, int field_width, int precision, int flags)
> > +{
> > + int len, i;
> > +
> > + if ((unsigned long)s < PAGE_SIZE)
> > + s = "<NULL>";
>
> hm, is that needed for other reasons than "it will fault"?
It's similar to what glibc does - showing a NULL ptr gracefully. They are
pretty common, and it's very rude to SIGSEGV or oops just because you
wanted to print a string out for debugging.
The code is also just copied from the old code - just moved it to a
function of its own.
> otherwise we could walk the whole string with probe_kernel_address()
> before we do anything with it.
That would be pretty slow, wed' be better off then unrolling it (ie doing
all the ugly setup around the whole string).
> If this takes off we might want a register-your-printk-handler
> interface. Maybe.
Yeah.
> We also jump through hoops to print things like sector_t and
> resource_size_t. They always need to be cast to `unsiged long long',
> which generates additional stack space and text in some setups.
Indeed. Though doing it with a pointer is often not a _whole_ lot cleaner,
but yes, it's often nicer to add a '&' than adding a cast.
> And then there's the perennial "need to cast u64 to unsigned long long
> to print it". If we were to do
>
> printk("%SL", (void *)some_u64);
>
> then that's still bloody ugly, but it'll save a little text-n-stack.
No can do. (void *) isn't big enough to hold a u64. So it would have to be
something like this:
printk("%p64i", &some_u64);
instead. Avoiding the cast, and often being more efficient calling
convention on 32-bit.
But it can often generate worse code too - now we're taking an address of
a variable, and that will disable many optimizations because now i's not a
purely local variable that the compiler knows all uses for any more.
So I'm not entirely conviced it's a good idea to do this for just "long
long" cases. Dunno.
Linus
^ permalink raw reply
* Re: the printk problem
From: Matthew Wilcox @ 2008-07-04 20:42 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, linux-ia64, Linus Torvalds, David S. Miller,
Peter Anvin
In-Reply-To: <20080704132716.f1e12554.akpm@linux-foundation.org>
On Fri, Jul 04, 2008 at 01:27:16PM -0700, Andrew Morton wrote:
> On Fri, 4 Jul 2008 13:02:05 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > so I think we could easily just say that we extend %p in various ways:
> > >
> > > - %pS - print pointer as a symbol
> > >
> > > and leave tons of room for future extensions for different kinds of
> > > pointers.
>
> If this takes off we might want a register-your-printk-handler
> interface. Maybe.
>
> We also jump through hoops to print things like sector_t and
> resource_size_t. They always need to be cast to `unsiged long long',
> which generates additional stack space and text in some setups.
The thing is that GCC checks types. So it's fine to add "print this
pointer specially", but you can't in general add new printf arguments
without also hacking GCC. Unless you use -Wno-format, and require
sparse to check special kernel types.
> And then there's the perennial "need to cast u64 to unsigned long long
> to print it". If we were to do
>
> printk("%SL", (void *)some_u64);
>
> then that's still bloody ugly, but it'll save a little text-n-stack.
u64 is easy to fix, and I don't know why we haven't. Just make it
unsigned long long on all architectures.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Mark Brown @ 2008-07-04 20:49 UTC (permalink / raw)
To: Grant Likely; +Cc: liam.girdwood, alsa-devel, timur, linuxppc-dev
In-Reply-To: <20080701235340.16923.48024.stgit@trillian.secretlab.ca>
On Tue, Jul 01, 2008 at 05:53:40PM -0600, Grant Likely wrote:
> +static ssize_t aic26_keyclick_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct aic26 *aic26 = dev_get_drvdata(dev);
> + int val, amp, freq, len;
> +
> + val = aic26_reg_read_cache(&aic26->codec, AIC26_REG_AUDIO_CTRL2);
> + amp = (val >> 12) & 0x7;
> + freq = (125 << ((val >> 8) & 0x7)) >> 1;
> + len = 2 * (1 +((val >> 8) & 0xf));
> +
> + return sprintf(buf, "amp=%x freq=%iHz len=%iclks\n", amp, freq, len);
> +}
It might be nice if these parameters were exposed as controls if they
can be configured, though obviously that's not essential.
> + /* Tell the of_soc helper about this codec */
> + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
> + spi->dev.archdata.of_node);
Does this need to be ifdefed out if of_snd_soc_register_codec() is not
in use or is the function stubbed out if it's not in use? Stubbing it
out would be cleaner.
^ permalink raw reply
* Re: the printk problem
From: Andrew Morton @ 2008-07-04 22:01 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-ia64, linux-kernel, linuxppc-dev, Peter Anvin,
Linus Torvalds, David S. Miller
In-Reply-To: <20080704204252.GM14894@parisc-linux.org>
(heck, let's cc lkml - avoid having to go through all this again)
On Fri, 4 Jul 2008 14:42:53 -0600 Matthew Wilcox <matthew@wil.cx> wrote:
> On Fri, Jul 04, 2008 at 01:27:16PM -0700, Andrew Morton wrote:
> > On Fri, 4 Jul 2008 13:02:05 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > > > so I think we could easily just say that we extend %p in various ways:
> > > >
> > > > - %pS - print pointer as a symbol
> > > >
> > > > and leave tons of room for future extensions for different kinds of
> > > > pointers.
> >
> > If this takes off we might want a register-your-printk-handler
> > interface. Maybe.
> >
> > We also jump through hoops to print things like sector_t and
> > resource_size_t. They always need to be cast to `unsiged long long',
> > which generates additional stack space and text in some setups.
>
> The thing is that GCC checks types. So it's fine to add "print this
> pointer specially", but you can't in general add new printf arguments
> without also hacking GCC. Unless you use -Wno-format, and require
> sparse to check special kernel types.
It would be excellent if gcc had an extension system so that you could
add new printf control chars and maybe even tell gcc how to check them.
But of course, if that were to happen, we couldn't use it for 4-5 years.
What I had initially proposed was to abuse %S, which takes a wchar_t*.
gcc accepts `unsigned long *' for %S.
Then, we put the kernel-specific control char after the S, so we can
print an inode (rofl) with
struct inode *inode;
printk("here is an inode: %Si\n", (unsigned long *)inode);
Downsides are:
- there's a cast, so you could accidentally do
printk("here is an inode: %Si\n", (unsigned long *)dentry);
- there's a cast, and they're ugly
- gcc cannot of course check that the arg matches the control string
Unfortunately (and this seems weird), gcc printf checking will not
accept a void* for %S: it _has_ to be wchar_t*, and the checker won't
permit void* substitution for that.
Anyway, Linus took all that and said "let's abuse %p instead". It
_will_ accept any pointer so we can instead do:
printk("here is an inode: %pi\n", inode);
which is nicer.
I think the main customers of this are print_symbol():
printk("I am about to call %ps\n", fn);
(*fn)();
and NIPQUAD and its ipv6 version.
We don't know how much interest there would be in churning NIPQUAD from
the net guys. Interestingly, there's also %C (wint_t) which is a
32-bit quantity. So we could just go and say "%C prints an ipv4
address" and be done with it. But there's no way of doing that for
ipv6 addresses so things would become asymmetrical there.
Another customer is net mac addresses. There are surely others. One
which should have been in printf 30 years ago was %b: binary.
> > And then there's the perennial "need to cast u64 to unsigned long long
> > to print it". If we were to do
> >
> > printk("%SL", (void *)some_u64);
> >
> > then that's still bloody ugly, but it'll save a little text-n-stack.
>
> u64 is easy to fix, and I don't know why we haven't. Just make it
> unsigned long long on all architectures.
Yeah. Why don't we do that?
^ permalink raw reply
* Re: patches for 2.6.27...
From: Segher Boessenkool @ 2008-07-04 22:33 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20080702105946.0ec1ffcc.kim.phillips@freescale.com>
>> Please point out any patches that have been posted but havent made it
>> into a git tree related to Freescale chips.
>
> I haven't heard back from Segher, so:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=19313
You haven't heard back because I feel like I'm talking to a wall.
The "compatible" definition for this node needs to be fixed.
Segher
^ permalink raw reply
* Re: [PATCH v3] powerpc: update crypto node definition and device tree instances
From: Segher Boessenkool @ 2008-07-04 22:45 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080703141845.af88fd51.kim.phillips@freescale.com>
> +- compatible : Should contain entries for this and backward compatible
> + SEC versions, high to low, e.g., "fsl,sec2.1", "fsl,sec2.0"
First entry should state the _exact_ version of the device. "sec-N.M"
isn't good enough; there can be implementation bugs.
There can be more entries; you make it sound like each device tree
should list _all_ compatible devices, which isn't the case.
A device binding should not (and can not) say how "compatible"
should be used; instead, it should list what values of "compatible"
this binding applies to. You can give recommendations of course.
> +- interrupts : <a b> where a is the interrupt number and b is a
> + field that represents an encoding of the sense and level
> + information for the interrupt. This should be encoded based on
> + the information in section 2) depending on the type of interrupt
> + controller you have.
#interrupt-cells isn't always 2. Your device binding shouldn't describe
how interrupt encoding works (that's described in the imap recommended
practice, already); instead, it should describe which device interrupts
are listed here, and in what order. Sounds like you only have one
interrupt, so that should be easy ;-)
> +- interrupt-parent : the phandle for the interrupt controller that
> + services interrupts for this device.
"interrupt-parent" isn't a required property. It isn't part of this
device binding, either.
Segher
^ permalink raw reply
* Re: the printk problem
From: Benjamin Herrenschmidt @ 2008-07-04 22:58 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-ia64, linuxppc-dev, Peter Anvin, Andrew Morton,
Linus Torvalds, David S. Miller
In-Reply-To: <20080704204252.GM14894@parisc-linux.org>
> u64 is easy to fix, and I don't know why we haven't. Just make it
> unsigned long long on all architectures.
Yup. Also, one of the major user of that is to print a struct resource,
which everybody does differently, so we may even look at doing a %pR
that does the nice start..end [attr]..
Ben.
^ permalink raw reply
* Re: New fsl device bindings file
From: Segher Boessenkool @ 2008-07-04 22:59 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev list
In-Reply-To: <20080703185312.GA6043@polina.dev.rtsoft.ru>
> Just curious... why we're maintaining documentation in the .txt file?
Because it is human-readable text?
> Or is this too wild? :-)
Yes :-)
Segher
^ permalink raw reply
* Re: the printk problem
From: Benjamin Herrenschmidt @ 2008-07-04 23:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: linuxppc-dev, Andrew Morton, linux-ia64, David S. Miller,
Peter Anvin
In-Reply-To: <alpine.LFD.1.10.0807041250220.2815@woody.linux-foundation.org>
On Fri, 2008-07-04 at 13:02 -0700, Linus Torvalds wrote:
>
> That function descriptor indirection is totally untested, and I did it
> with a
>
> pagefault_disable();
> __get_user(..)
> pagefault_enable();
>
> thing because I thought it would be nice if printk() was always safe, and
> passing bogus function pointers to '%pF' should try to work, but quite
> frankly, I didn't even check that that part compiles, much less works.
>
> ia64/ppc lists cc'd, just in case somebody wants to test this.
I'll give it a try using probe_kernel_address() instead on monday.
Cheers,
Ben.
^ permalink raw reply
* Re: New fsl device bindings file
From: Segher Boessenkool @ 2008-07-04 23:12 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev list
In-Reply-To: <486E26C0.9060604@genesi-usa.com>
>> /* deprecated; */
>> device_type =3D "i2c";
>
> How about "deprecated but kept for compatibility with true Open=20
> Firmware
> implementations"?
Well, except a flat tree isn't compatible with OF at all here.
A "device_type" promises a certain interface; a flat tree doesn't
even have the "open" method. =46rom the OF base spec:
=93device_type=94 S
Standard property name to specify the implemented interface.
prop-encoded-array: Text string encoded with encode-string.
Specifies the =93device type=94 of this package, thus implying a
specific set of package class methods implemented by this
package.
> Seriously, you can't have a binding for "OF" and then cut out that=20
> part of the
> standard at a whim.
Nothing is cut out. There never was a device binding for device_type
i2c; creating one would be a considerable effort, and since flat tree
users wouldn't use it anyway, you can't be seriously suggesting they
should do this.
> It should be there (at least for those parts which are
> governed by a client interface API, like display, serial etc.
Huh? Nothing in the client interface mentions display or serial
as far as I know.
> but cutting it off takes away all it's meaning,
So what? There _is_ no "real" device interface, when a flat tree is
used.
> plus Linux implementations STILL keep searching
> that property along with "compatible",
That's a bug.
Segher
^ permalink raw reply
* Re: New fsl device bindings file
From: Segher Boessenkool @ 2008-07-04 23:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <40B88BFD-1FEB-4E36-9917-54C7380FF801@kernel.crashing.org>
> I'm sure you'll hate for doing this,
No, it's an excellent move :-)
> but I've asked Kim to create a new
> Documentation/powerpc/fsl-device-tree-bindings.txt as part of his SEC
> patch.
As a separate patch, that (at first) _only_ moves the content into
separate
files, please.
Segher
^ permalink raw reply
* Re: the printk problem
From: Linus Torvalds @ 2008-07-04 23:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-ia64, linuxppc-dev, Peter Anvin, Andrew Morton,
David S. Miller, parisc-linux
In-Reply-To: <1215212420.8970.8.camel@pasglop>
On Sat, 5 Jul 2008, Benjamin Herrenschmidt wrote:
>
> I'll give it a try using probe_kernel_address() instead on monday.
Here's the updated patch which uses probe_kernel_address() instead (and
moves the whole #ifdef mess out of the code that wants it and into a
helper function - and maybe we should then put that helper into
kallsyms.h, but that's a different issue).
Still all happily untested, of course. And still with no actual users
converted.
Linus
---
lib/vsprintf.c | 108 +++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 80 insertions(+), 28 deletions(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 6021757..1fbb1c0 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -22,6 +22,8 @@
#include <linux/string.h>
#include <linux/ctype.h>
#include <linux/kernel.h>
+#include <linux/kallsyms.h>
+#include <linux/uaccess.h>
#include <asm/page.h> /* for PAGE_SIZE */
#include <asm/div64.h>
@@ -482,6 +484,77 @@ static char *number(char *buf, char *end, unsigned long long num, int base, int
return buf;
}
+static char *string(char *buf, char *end, char *s, int field_width, int precision, int flags)
+{
+ int len, i;
+
+ if ((unsigned long)s < PAGE_SIZE)
+ s = "<NULL>";
+
+ len = strnlen(s, precision);
+
+ if (!(flags & LEFT)) {
+ while (len < field_width--) {
+ if (buf < end)
+ *buf = ' ';
+ ++buf;
+ }
+ }
+ for (i = 0; i < len; ++i) {
+ if (buf < end)
+ *buf = *s;
+ ++buf; ++s;
+ }
+ while (len < field_width--) {
+ if (buf < end)
+ *buf = ' ';
+ ++buf;
+ }
+ return buf;
+}
+
+static inline void *dereference_function_descriptor(void *ptr)
+{
+#if defined(CONFIG_IA64) || defined(CONFIG_PPC64)
+ void *p;
+ if (!probe_kernel_address(ptr, p))
+ ptr = p;
+#endif
+ return ptr;
+}
+
+
+/*
+ * Show a '%p' thing. A kernel extension is that the '%p' is followed
+ * by an extra set of alphanumeric characters that are extended format
+ * specifiers. Right now we just handle 'F' (for symbolic Function
+ * pointers) and 'S' (for Symbolic data pointers), but this can easily
+ * be extended in the future (network address types etc).
+ *
+ * The difference between 'S' and 'F' is that on ia64 and ppc64 function
+ * pointers are really function descriptors, which contain a pointer the
+ * real address.
+ */
+static char *pointer(const char *fmt, char *buf, char *end, void *ptr, int base, int size, int precision, int type)
+{
+ switch (*fmt) {
+ case 'F':
+ ptr = dereference_function_descriptor(ptr);
+ /* Fallthrough */
+ case 'S': { /* Other (direct) pointer */
+#if CONFIG_KALLSYMS
+ char sym[KSYM_SYMBOL_LEN];
+ sprint_symbol(sym, (unsigned long) ptr);
+ return string(buf, end, sym, size, precision, type);
+#else
+ type |= SPECIAL;
+ break;
+#endif
+ }
+ }
+ return number(buf, end, (unsigned long long) ptr, base, size, precision, type);
+}
+
/**
* vsnprintf - Format a string and place it in a buffer
* @buf: The buffer to place the result into
@@ -502,11 +575,9 @@ static char *number(char *buf, char *end, unsigned long long num, int base, int
*/
int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
{
- int len;
unsigned long long num;
- int i, base;
+ int base;
char *str, *end, c;
- const char *s;
int flags; /* flags to number() */
@@ -622,29 +693,7 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
continue;
case 's':
- s = va_arg(args, char *);
- if ((unsigned long)s < PAGE_SIZE)
- s = "<NULL>";
-
- len = strnlen(s, precision);
-
- if (!(flags & LEFT)) {
- while (len < field_width--) {
- if (str < end)
- *str = ' ';
- ++str;
- }
- }
- for (i = 0; i < len; ++i) {
- if (str < end)
- *str = *s;
- ++str; ++s;
- }
- while (len < field_width--) {
- if (str < end)
- *str = ' ';
- ++str;
- }
+ str = string(str, end, va_arg(args, char *), field_width, precision, flags);
continue;
case 'p':
@@ -653,9 +702,12 @@ int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
field_width = 2*sizeof(void *);
flags |= ZEROPAD;
}
- str = number(str, end,
- (unsigned long) va_arg(args, void *),
+ str = pointer(fmt+1, str, end,
+ va_arg(args, void *),
16, field_width, precision, flags);
+ /* Skip all alphanumeric pointer suffixes */
+ while (isalnum(fmt[1]))
+ fmt++;
continue;
^ permalink raw reply related
* Re: [PATCH v2 3/5] of-bindings: Add binding documentation for SPI busses and devices
From: Segher Boessenkool @ 2008-07-04 23:36 UTC (permalink / raw)
To: Grant Likely
Cc: david-b, spi-devel-general, fabrizio.garetto, linux-kernel,
linuxppc-dev
In-Reply-To: <20080703010308.26187.23037.stgit@trillian.secretlab.ca>
> + The SPI master node requires the following properties:
> + - #address-cells - number of cells required to define a chip
> select
> + address on the SPI bus.
Hrm. Should this (and "reg" in the child node) be required for SPI
masters that have only one chip select?
> + - max-speed - (required) Maximum SPI clocking speed of
> device in Hz
The property name should include something "SPI", it's way too generic
otherwise.
> + - spi,cpol - (optional) Device requires inverse clock
> polarity
> + - spi,cpha - (optional) Device requires shifted clock phase
Don't abbr the property names, there's nothing wrong with longer names.
The names shouldn't start with "spi," either, "spi" isn't a vendor;
how about "spi-inverse-clock-polarity" or similar?
> + - linux,modalias - (optional, Linux specific) Force binding of
> SPI device
> + to a particular spi_device driver. Useful for changing
> + driver binding between spidev and a kernel SPI driver.
This is a temporary workaround I hope?
Segher
^ permalink raw reply
* Re: [PATCH v2 3/5] of-bindings: Add binding documentation for SPI busses and devices
From: Grant Likely @ 2008-07-04 23:42 UTC (permalink / raw)
To: Segher Boessenkool
Cc: david-b, spi-devel-general, fabrizio.garetto, linux-kernel,
linuxppc-dev
In-Reply-To: <1694b01b1b41f244e565298b430f021c@kernel.crashing.org>
On Fri, Jul 4, 2008 at 5:36 PM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>> + The SPI master node requires the following properties:
>> + - #address-cells - number of cells required to define a chip select
>> + address on the SPI bus.
>
> Hrm. Should this (and "reg" in the child node) be required for SPI
> masters that have only one chip select?
I suppose it could be skipped, but I'd rather have it there for consistency
>
>> + - max-speed - (required) Maximum SPI clocking speed of device
>> in Hz
>
> The property name should include something "SPI", it's way too generic
> otherwise.
Good point; I'll change this to 'spi-max-speed'
>> + - spi,cpol - (optional) Device requires inverse clock polarity
>> + - spi,cpha - (optional) Device requires shifted clock phase
>
> Don't abbr the property names, there's nothing wrong with longer names.
> The names shouldn't start with "spi," either, "spi" isn't a vendor;
> how about "spi-inverse-clock-polarity" or similar?
Okay, but cpol and cpha are common abbreviations w.r.t. SPI devices.
>> + - linux,modalias - (optional, Linux specific) Force binding of SPI
>> device
>> + to a particular spi_device driver. Useful for
>> changing
>> + driver binding between spidev and a kernel SPI
>> driver.
>
> This is a temporary workaround I hope?
Yeah, I'm kind of ashamed of this one. I'll drop it.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
From: Grant Likely @ 2008-07-04 23:44 UTC (permalink / raw)
To: Grant Likely, liam.girdwood, alsa-devel, linuxppc-dev, timur
In-Reply-To: <20080704204927.GC20719@sirena.org.uk>
On Fri, Jul 4, 2008 at 2:49 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Jul 01, 2008 at 05:53:40PM -0600, Grant Likely wrote:
>> + /* Tell the of_soc helper about this codec */
>> + of_snd_soc_register_codec(&aic26_soc_codec_dev, aic26, &aic26_dai,
>> + spi->dev.archdata.of_node);
>
> Does this need to be ifdefed out if of_snd_soc_register_codec() is not
> in use or is the function stubbed out if it's not in use? Stubbing it
> out would be cleaner.
yeah, probably. This is a stop-gap measure anyway until ASoC v2 is merged.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: New fsl device bindings file
From: David Gibson @ 2008-07-05 1:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev list
In-Reply-To: <e88aa775e8f6dcc85f1e4b9c3ca28fdd@kernel.crashing.org>
On Sat, Jul 05, 2008 at 01:12:31AM +0200, Segher Boessenkool wrote:
>>> /* deprecated; */
>>> device_type = "i2c";
>>
>> How about "deprecated but kept for compatibility with true Open
>> Firmware
>> implementations"?
>
> Well, except a flat tree isn't compatible with OF at all here.
> A "device_type" promises a certain interface; a flat tree doesn't
> even have the "open" method. From the OF base spec:
>
> “device_type” S
>
> Standard property name to specify the implemented interface.
>
> prop-encoded-array: Text string encoded with encode-string.
>
> Specifies the “device type” of this package, thus implying a
> specific set of package class methods implemented by this
> package.
>
>> Seriously, you can't have a binding for "OF" and then cut out that
>> part of the
>> standard at a whim.
>
> Nothing is cut out. There never was a device binding for device_type
> i2c; creating one would be a considerable effort, and since flat tree
> users wouldn't use it anyway, you can't be seriously suggesting they
> should do this.
>
>> It should be there (at least for those parts which are
>> governed by a client interface API, like display, serial etc.
>
> Huh? Nothing in the client interface mentions display or serial
> as far as I know.
>
>> but cutting it off takes away all it's meaning,
>
> So what? There _is_ no "real" device interface, when a flat tree is
> used.
>
>> plus Linux implementations STILL keep searching
>> that property along with "compatible",
>
> That's a bug.
Thank you Segher, you saved me the trouble of saying exactly all that.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [alsa-devel] [PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
From: David Gibson @ 2008-07-05 1:28 UTC (permalink / raw)
To: Timur Tabi; +Cc: liam.girdwood, alsa-devel, broonie, linuxppc-dev
In-Reply-To: <B7AF0D32-4A05-4DE1-88F5-06B28C9723EF@freescale.com>
On Fri, Jul 04, 2008 at 07:03:25AM -0400, Timur Tabi wrote:
>> i2s@2200 { // PSC2
>> compatible = "fsl,mpc5200b-psc-i2s","fsl,mpc5200-psc-i2s";
>> cell-index = <1>;
>
> cell-index should be zero-based, not one-based.
Well...since cell-index is for indexing shared resources, the
cell-index values should be whatever the convention is for that shared
resource, which can be defined as whatever is convenient for that
resource. I think that's been zero-based in every user of cell-index
so far, but there's no reason it *has* to be if a different
enumeration is convenient for the shared resource in question.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: the printk problem
From: Matthew Wilcox @ 2008-07-05 2:03 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-ia64, linux-kernel, linuxppc-dev, Peter Anvin,
Linus Torvalds, David S. Miller
In-Reply-To: <20080704150100.1f7b8a65.akpm@linux-foundation.org>
On Fri, Jul 04, 2008 at 03:01:00PM -0700, Andrew Morton wrote:
> (heck, let's cc lkml - avoid having to go through all this again)
>
> It would be excellent if gcc had an extension system so that you could
> add new printf control chars and maybe even tell gcc how to check them.
> But of course, if that were to happen, we couldn't use it for 4-5 years.
I believe NetBSD added that as an extension many years ago. Dunno if
they still have it.
> What I had initially proposed was to abuse %S, which takes a wchar_t*.
> gcc accepts `unsigned long *' for %S.
>
[...]
> - there's a cast, so you could accidentally do
>
> printk("here is an inode: %Si\n", (unsigned long *)dentry);
>
> - there's a cast, and they're ugly
>
> - gcc cannot of course check that the arg matches the control string
>
> Unfortunately (and this seems weird), gcc printf checking will not
> accept a void* for %S: it _has_ to be wchar_t*, and the checker won't
> permit void* substitution for that.
Presumably that's the compiler getting rid of the first and third
downside ;-)
> Anyway, Linus took all that and said "let's abuse %p instead". It
> _will_ accept any pointer so we can instead do:
>
> printk("here is an inode: %pi\n", inode);
>
> which is nicer.
Yes. It's possible to confuse it, of course.
printk("Function %pSucks\n", sys_open);
but I really doubt we have such a usage in the kernel today.
> > u64 is easy to fix, and I don't know why we haven't. Just make it
> > unsigned long long on all architectures.
>
> Yeah. Why don't we do that?
Patch ...
[PATCH] Make u64 long long on all architectures
It is currently awkward to print a u64 type. Some architectures use
unsigned long while others use unsigned long long. Since unsigned long
long is 64-bit for all existing Linux architectures, change those that
use long to use long long. Note that this applies only within the
kernel. If u64 is being used in a C++ method definition, the symbol
mangling would change.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
index 2af9b75..32f07bd 100644
--- a/include/asm-generic/int-l64.h
+++ b/include/asm-generic/int-l64.h
@@ -23,8 +23,13 @@ typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
+#ifdef __KERNEL__
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#else
typedef __signed__ long __s64;
typedef unsigned long __u64;
+#endif
#endif /* __ASSEMBLY__ */
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply related
* Re: [PATCH] Add PPC_FEATURE_PMU_COMPAT
From: Olof Johansson @ 2008-07-05 5:10 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080703232001.GB9594@localdomain>
On Jul 3, 2008, at 6:20 PM, Nathan Lynch wrote:
> Beginning with Power6, there is a set of 32 PMU events which is
> compatible across POWER processor lines. PPC_FEATURE_PMU_COMPAT
> indicates support for this subset.
The PMU isn't, as far as I know, part of the architecture, it's up to
each implementation to do as it pleases. Right? So this should
probably be named less generic.
-Olof
^ permalink raw reply
* Re: New fsl device bindings file
From: Olof Johansson @ 2008-07-05 5:24 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev list
In-Reply-To: <fa686aa40807031134s4ddd0cabj1b31d3ee2d9d2258@mail.gmail.com>
On Jul 3, 2008, at 1:34 PM, Grant Likely wrote:
>> How about splitting up like this:
>>
>> Documentation/powerpc/device-tree/fsl/cpm.txt
>> Documentation/powerpc/device-tree/fsl/cpm/uart.txt
>> Documentation/powerpc/device-tree/fsl/tsec.txt
>> Documentation/powerpc/device-tree/interrupts.txt
>> Documentation/powerpc/device-tree/dtb.txt
>
> May I suggest moving it to Documentation/of-bindings/ instead? Some
> of these bindings (granted, not the fsl ones) will be used by
> non-powerpc platforms (sparc, microblaze).
Good idea, but:
Don't call the bindings OF. They're not.
They are a linux-specific binding that happens to use the same data
structures and representation that OF does.
Call them dts-bindings or something else, just to avoid confusion.
-Olof
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Michael Ellerman @ 2008-07-05 5:43 UTC (permalink / raw)
To: arnd; +Cc: Paul Mackerras, cbe-oss-dev, linuxppc-dev
In-Reply-To: <20080704190806.964824190@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Fri, 2008-07-04 at 21:05 +0200, arnd@arndb.de wrote:
> Introduce a new dma attriblue DMA_ATTR_STRONG_ORDERING to use strong ordering
> on DMA mappings in the Cell processor. Add the code to the Cell's IOMMU
> implementation to use this.
>
> The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs
> (for both the dynamic and fixed mappings) which enforces strong ordering of
> both reads and writes. This patch makes the default behaviour weak ordering
> (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the
> new DMA_ATTR_STRONG_ORDERING needs to be used.
We're sure that's safe?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 11/11] powerpc/cell: Add DMA_ATTR_STRONG_ORDERING dma attribute and use in IOMMU code
From: Benjamin Herrenschmidt @ 2008-07-05 6:28 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras, cbe-oss-dev, arnd
In-Reply-To: <1215236584.7424.2.camel@localhost>
On Sat, 2008-07-05 at 15:43 +1000, Michael Ellerman wrote:
> > The current Cell IOMMU implementation sets the IOPTE_SO_RW bits in all IOTPEs
> > (for both the dynamic and fixed mappings) which enforces strong ordering of
> > both reads and writes. This patch makes the default behaviour weak ordering
> > (the IOPTE_SO_RW bits not set) and to request a strongly ordered mapping the
> > new DMA_ATTR_STRONG_ORDERING needs to be used.
>
> We're sure that's safe?
I'd say it's not...
Ben.
^ permalink raw reply
* Re: New fsl device bindings file
From: Grant Likely @ 2008-07-05 6:53 UTC (permalink / raw)
To: Segher Boessenkool, Matt Sealey, linuxppc-dev list
In-Reply-To: <20080705012624.GA3032@yookeroo.seuss>
On Sat, Jul 05, 2008 at 11:26:24AM +1000, David Gibson wrote:
> On Sat, Jul 05, 2008 at 01:12:31AM +0200, Segher Boessenkool wrote:
> >>> /* deprecated; */
> >>> device_type = "i2c";
> >>
> >> How about "deprecated but kept for compatibility with true Open
> >> Firmware
> >> implementations"?
> >
> > Well, except a flat tree isn't compatible with OF at all here.
> > A "device_type" promises a certain interface; a flat tree doesn't
> > even have the "open" method. From the OF base spec:
> >
> > “device_type” S
> >
> > Standard property name to specify the implemented interface.
> >
> > prop-encoded-array: Text string encoded with encode-string.
> >
> > Specifies the “device type” of this package, thus implying a
> > specific set of package class methods implemented by this
> > package.
> >
> >> Seriously, you can't have a binding for "OF" and then cut out that
> >> part of the
> >> standard at a whim.
> >
> > Nothing is cut out. There never was a device binding for device_type
> > i2c; creating one would be a considerable effort, and since flat tree
> > users wouldn't use it anyway, you can't be seriously suggesting they
> > should do this.
> >
> >> It should be there (at least for those parts which are
> >> governed by a client interface API, like display, serial etc.
> >
> > Huh? Nothing in the client interface mentions display or serial
> > as far as I know.
> >
> >> but cutting it off takes away all it's meaning,
> >
> > So what? There _is_ no "real" device interface, when a flat tree is
> > used.
> >
> >> plus Linux implementations STILL keep searching
> >> that property along with "compatible",
> >
> > That's a bug.
>
> Thank you Segher, you saved me the trouble of saying exactly all that.
Ditto.
g.
^ permalink raw reply
* [PATCH v3] ibm_newemac: Parameterize EMAC Multicast Match Handling
From: Grant Erickson @ 2008-07-05 9:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sr
In-Reply-To: <C48F0E18.101F1%gerickson@nuovations.com>
Various instances of the EMAC core have varying: 1) number of address
match slots, 2) width of the registers for handling address match slots,
3) number of registers for handling address match slots and 4) base
offset for those registers.
As the driver stands today, it assumes that all EMACs have 4 IAHT and
GAHT 32-bit registers, starting at offset 0x30 from the register base,
with only 16-bits of each used for a total of 64 match slots.
The 405EX(r) and 460EX now use the EMAC4SYNC core rather than the EMAC4
core. This core has 8 IAHT and GAHT registers, starting at offset 0x80
from the register base, with ALL 32-bits of each used for a total of
256 match slots.
This adds a new compatible device tree entry "emac4sync" and a new,
related feature flag "EMAC_FTR_EMAC4SYNC" along with a series of macros
and inlines which supply the appropriate parameterized value based on
the presence or absence of the EMAC4SYNC feature.
The code has further been reworked where appropriate to use those macros
and inlines.
In addition, the register size passed to ioremap is now taken from the
device tree:
c0 for EMAC4SYNC cores
74 for EMAC4 cores
70 for EMAC cores
rather than sizeof (emac_regs).
Finally, the device trees have been updated with the appropriate compatible
entries and resource sizes.
This has been tested on an AMCC Haleakala board such that: 1) inbound
ICMP requests to 'haleakala.local' via MDNS from both Mac OS X 10.4.11
and Ubuntu 8.04 systems as well as 2) outbound ICMP requests from
'haleakala.local' to those same systems in the '.local' domain via MDNS
now work.
Signed-off-by: Grant Erickson <gerickson@nuovations.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 8 ++--
arch/powerpc/boot/dts/glacier.dts | 8 ++--
arch/powerpc/boot/dts/haleakala.dts | 4 +-
arch/powerpc/boot/dts/katmai.dts | 2 +-
arch/powerpc/boot/dts/kilauea.dts | 8 ++--
arch/powerpc/boot/dts/makalu.dts | 8 ++--
arch/powerpc/boot/dts/rainier.dts | 4 +-
arch/powerpc/boot/dts/sequoia.dts | 4 +-
arch/powerpc/boot/dts/taishan.dts | 8 ++--
drivers/net/ibm_newemac/core.c | 60 +++++++++++++++++-------
drivers/net/ibm_newemac/core.h | 83 ++++++++++++++++++++++++++++++++-
drivers/net/ibm_newemac/debug.c | 32 ++++++++-----
drivers/net/ibm_newemac/emac.h | 15 +------
13 files changed, 172 insertions(+), 72 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
index 3963412..b2811ea 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -264,7 +264,7 @@
EMAC0: ethernet@ef600e00 {
device_type = "network";
- compatible = "ibm,emac-460ex", "ibm,emac4";
+ compatible = "ibm,emac-460ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -272,7 +272,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -293,7 +293,7 @@
EMAC1: ethernet@ef600f00 {
device_type = "network";
- compatible = "ibm,emac-460ex", "ibm,emac4";
+ compatible = "ibm,emac-460ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -301,7 +301,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
index 0f2fc07..8ffde9b 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -281,7 +281,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 10 4
/*Wake*/ 1 &UIC2 14 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -310,7 +310,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 11 4
/*Wake*/ 1 &UIC2 15 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
@@ -340,7 +340,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 12 4
/*Wake*/ 1 &UIC2 16 4>;
- reg = <ef601100 70>;
+ reg = <ef601100 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <2>;
@@ -368,7 +368,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC2 13 4
/*Wake*/ 1 &UIC2 17 4>;
- reg = <ef601200 70>;
+ reg = <ef601200 74>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <3>;
diff --git a/arch/powerpc/boot/dts/haleakala.dts b/arch/powerpc/boot/dts/haleakala.dts
index b5d95ac..0ae3e07 100644
--- a/arch/powerpc/boot/dts/haleakala.dts
+++ b/arch/powerpc/boot/dts/haleakala.dts
@@ -204,7 +204,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405exr", "ibm,emac4";
+ compatible = "ibm,emac-405exr", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -212,7 +212,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index cc2873a..c91bb66 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -206,7 +206,7 @@
compatible = "ibm,emac-440spe", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
- reg = <10000800 70>;
+ reg = <10000800 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 48c9a6e..e6633a0 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -205,7 +205,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -213,7 +213,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -233,7 +233,7 @@
EMAC1: ethernet@ef600a00 {
linux,network-index = <1>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -241,7 +241,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600a00 70>;
+ reg = <ef600900 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/makalu.dts b/arch/powerpc/boot/dts/makalu.dts
index 84cc5e7..659b960 100644
--- a/arch/powerpc/boot/dts/makalu.dts
+++ b/arch/powerpc/boot/dts/makalu.dts
@@ -205,7 +205,7 @@
EMAC0: ethernet@ef600900 {
linux,network-index = <0>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC0>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -213,7 +213,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600900 70>;
+ reg = <ef600900 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -233,7 +233,7 @@
EMAC1: ethernet@ef600a00 {
linux,network-index = <1>;
device_type = "network";
- compatible = "ibm,emac-405ex", "ibm,emac4";
+ compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0 1>;
#interrupt-cells = <1>;
@@ -241,7 +241,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600a00 70>;
+ reg = <ef600900 c0>;
local-mac-address = [000000000000]; /* Filled in by U-Boot */
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/rainier.dts b/arch/powerpc/boot/dts/rainier.dts
index 6a8fa70..026c22c 100644
--- a/arch/powerpc/boot/dts/rainier.dts
+++ b/arch/powerpc/boot/dts/rainier.dts
@@ -263,7 +263,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -292,7 +292,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
index 72d6756..8d66c99 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -278,7 +278,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 18 4
/*Wake*/ 1 &UIC1 1d 4>;
- reg = <ef600e00 70>;
+ reg = <ef600e00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -307,7 +307,7 @@
#size-cells = <0>;
interrupt-map = </*Status*/ 0 &UIC0 19 4
/*Wake*/ 1 &UIC1 1f 4>;
- reg = <ef600f00 70>;
+ reg = <ef600f00 74>;
local-mac-address = [000000000000];
mal-device = <&MAL0>;
mal-tx-channel = <1>;
diff --git a/arch/powerpc/boot/dts/taishan.dts b/arch/powerpc/boot/dts/taishan.dts
index e808e1c..f736d87 100644
--- a/arch/powerpc/boot/dts/taishan.dts
+++ b/arch/powerpc/boot/dts/taishan.dts
@@ -258,7 +258,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1c 4 1d 4>;
- reg = <40000800 70>;
+ reg = <40000800 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <0>;
@@ -278,7 +278,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC1>;
interrupts = <1e 4 1f 4>;
- reg = <40000900 70>;
+ reg = <40000900 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <1>;
@@ -298,7 +298,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
interrupts = <0 4 1 4>;
- reg = <40000c00 70>;
+ reg = <40000c00 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <2>;
@@ -322,7 +322,7 @@
compatible = "ibm,emac-440gx", "ibm,emac4";
interrupt-parent = <&UIC2>;
interrupts = <2 4 3 4>;
- reg = <40000e00 70>;
+ reg = <40000e00 74>;
local-mac-address = [000000000000]; // Filled in by zImage
mal-device = <&MAL0>;
mal-tx-channel = <3>;
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 5d2108c..931a061 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -363,25 +363,32 @@ static int emac_reset(struct emac_instance *dev)
static void emac_hash_mc(struct emac_instance *dev)
{
- struct emac_regs __iomem *p = dev->emacp;
- u16 gaht[4] = { 0 };
+ const int regs = EMAC_XAHT_REGS(dev);
+ u32 *gaht_base = emac_gaht_base(dev);
+ u32 gaht_temp[regs];
struct dev_mc_list *dmi;
+ int i;
DBG(dev, "hash_mc %d" NL, dev->ndev->mc_count);
+ memset(gaht_temp, 0, sizeof (gaht_temp));
+
for (dmi = dev->ndev->mc_list; dmi; dmi = dmi->next) {
- int bit;
+ int slot, reg, mask;
DBG2(dev, "mc %02x:%02x:%02x:%02x:%02x:%02x" NL,
dmi->dmi_addr[0], dmi->dmi_addr[1], dmi->dmi_addr[2],
dmi->dmi_addr[3], dmi->dmi_addr[4], dmi->dmi_addr[5]);
- bit = 63 - (ether_crc(ETH_ALEN, dmi->dmi_addr) >> 26);
- gaht[bit >> 4] |= 0x8000 >> (bit & 0x0f);
+ slot = EMAC_XAHT_CRC_TO_SLOT(dev, ether_crc(ETH_ALEN, dmi->dmi_addr));
+ reg = EMAC_XAHT_SLOT_TO_REG(dev, slot);
+ mask = EMAC_XAHT_SLOT_TO_MASK(dev, slot);
+
+ gaht_temp[reg] |= mask;
+ }
+
+ for (i = 0; i < regs; i++) {
+ out_be32(gaht_base + i, gaht_temp[i]);
}
- out_be32(&p->gaht1, gaht[0]);
- out_be32(&p->gaht2, gaht[1]);
- out_be32(&p->gaht3, gaht[2]);
- out_be32(&p->gaht4, gaht[3]);
}
static inline u32 emac_iff2rmr(struct net_device *ndev)
@@ -398,7 +405,8 @@ static inline u32 emac_iff2rmr(struct net_device *ndev)
if (ndev->flags & IFF_PROMISC)
r |= EMAC_RMR_PME;
- else if (ndev->flags & IFF_ALLMULTI || ndev->mc_count > 32)
+ else if (ndev->flags & IFF_ALLMULTI ||
+ (ndev->mc_count > EMAC_XAHT_SLOTS(dev)))
r |= EMAC_RMR_PMME;
else if (ndev->mc_count > 0)
r |= EMAC_RMR_MAE;
@@ -2015,10 +2023,10 @@ static int emac_get_regs_len(struct emac_instance *dev)
{
if (emac_has_feature(dev, EMAC_FTR_EMAC4))
return sizeof(struct emac_ethtool_regs_subhdr) +
- EMAC4_ETHTOOL_REGS_SIZE;
+ EMAC4_ETHTOOL_REGS_SIZE(dev);
else
return sizeof(struct emac_ethtool_regs_subhdr) +
- EMAC_ETHTOOL_REGS_SIZE;
+ EMAC_ETHTOOL_REGS_SIZE(dev);
}
static int emac_ethtool_get_regs_len(struct net_device *ndev)
@@ -2045,12 +2053,12 @@ static void *emac_dump_regs(struct emac_instance *dev, void *buf)
hdr->index = dev->cell_index;
if (emac_has_feature(dev, EMAC_FTR_EMAC4)) {
hdr->version = EMAC4_ETHTOOL_REGS_VER;
- memcpy_fromio(hdr + 1, dev->emacp, EMAC4_ETHTOOL_REGS_SIZE);
- return ((void *)(hdr + 1) + EMAC4_ETHTOOL_REGS_SIZE);
+ memcpy_fromio(hdr + 1, dev->emacp, EMAC4_ETHTOOL_REGS_SIZE(dev));
+ return ((void *)(hdr + 1) + EMAC4_ETHTOOL_REGS_SIZE(dev));
} else {
hdr->version = EMAC_ETHTOOL_REGS_VER;
- memcpy_fromio(hdr + 1, dev->emacp, EMAC_ETHTOOL_REGS_SIZE);
- return ((void *)(hdr + 1) + EMAC_ETHTOOL_REGS_SIZE);
+ memcpy_fromio(hdr + 1, dev->emacp, EMAC_ETHTOOL_REGS_SIZE(dev));
+ return ((void *)(hdr + 1) + EMAC_ETHTOOL_REGS_SIZE(dev));
}
}
@@ -2540,7 +2548,9 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
/* Check EMAC version */
- if (of_device_is_compatible(np, "ibm,emac4")) {
+ if (of_device_is_compatible(np, "ibm,emac4sync")) {
+ dev->features |= (EMAC_FTR_EMAC4 | EMAC_FTR_EMAC4SYNC);
+ } else if (of_device_is_compatible(np, "ibm,emac4")) {
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-440gx"))
dev->features |= EMAC_FTR_440GX_PHY_CLK_FIX;
@@ -2601,6 +2611,15 @@ static int __devinit emac_init_config(struct emac_instance *dev)
}
memcpy(dev->ndev->dev_addr, p, 6);
+ /* IAHT and GAHT filter parameterization */
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4SYNC)) {
+ dev->xaht_slots_shift = EMAC4SYNC_XAHT_SLOTS_SHIFT;
+ dev->xaht_width_shift = EMAC4SYNC_XAHT_WIDTH_SHIFT;
+ } else {
+ dev->xaht_slots_shift = EMAC4_XAHT_SLOTS_SHIFT;
+ dev->xaht_width_shift = EMAC4_XAHT_WIDTH_SHIFT;
+ }
+
DBG(dev, "features : 0x%08x / 0x%08x\n", dev->features, EMAC_FTRS_POSSIBLE);
DBG(dev, "tx_fifo_size : %d (%d gige)\n", dev->tx_fifo_size, dev->tx_fifo_size_gige);
DBG(dev, "rx_fifo_size : %d (%d gige)\n", dev->rx_fifo_size, dev->rx_fifo_size_gige);
@@ -2672,7 +2691,8 @@ static int __devinit emac_probe(struct of_device *ofdev,
goto err_irq_unmap;
}
// TODO : request_mem_region
- dev->emacp = ioremap(dev->rsrc_regs.start, sizeof(struct emac_regs));
+ dev->emacp = ioremap(dev->rsrc_regs.start,
+ dev->rsrc_regs.end - dev->rsrc_regs.start + 1);
if (dev->emacp == NULL) {
printk(KERN_ERR "%s: Can't map device registers!\n",
np->full_name);
@@ -2884,6 +2904,10 @@ static struct of_device_id emac_match[] =
.type = "network",
.compatible = "ibm,emac4",
},
+ {
+ .type = "network",
+ .compatible = "ibm,emac4sync",
+ },
{},
};
diff --git a/drivers/net/ibm_newemac/core.h b/drivers/net/ibm_newemac/core.h
index 1683db9..312bfa5 100644
--- a/drivers/net/ibm_newemac/core.h
+++ b/drivers/net/ibm_newemac/core.h
@@ -235,6 +235,10 @@ struct emac_instance {
u32 fifo_entry_size;
u32 mal_burst_size; /* move to MAL ? */
+ /* IAHT and GAHT filter parameterization */
+ u32 xaht_slots_shift;
+ u32 xaht_width_shift;
+
/* Descriptor management
*/
struct mal_descriptor *tx_desc;
@@ -309,6 +313,10 @@ struct emac_instance {
* Set if we need phy clock workaround for 440ep or 440gr
*/
#define EMAC_FTR_440EP_PHY_CLK_FIX 0x00000100
+/*
+ * The 405EX and 460EX contain the EMAC4SYNC core
+ */
+#define EMAC_FTR_EMAC4SYNC 0x00000200
/* Right now, we don't quite handle the always/possible masks on the
@@ -320,7 +328,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_EMAC4 | EMAC_FTR_EMAC4SYNC |
+ EMAC_FTR_HAS_NEW_STACR |
EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
@@ -342,6 +351,71 @@ static inline int emac_has_feature(struct emac_instance *dev,
(EMAC_FTRS_POSSIBLE & dev->features & feature);
}
+/*
+ * Various instances of the EMAC core have varying 1) number of
+ * address match slots, 2) width of the registers for handling address
+ * match slots, 3) number of registers for handling address match
+ * slots and 4) base offset for those registers.
+ *
+ * These macros and inlines handle these differences based on
+ * parameters supplied by the device tree.
+ */
+
+#define EMAC4_XAHT_SLOTS_SHIFT 6
+#define EMAC4_XAHT_WIDTH_SHIFT 4
+#define EMAC4_XAHT_BASE_OFFSET 0x30
+
+#define EMAC4SYNC_XAHT_SLOTS_SHIFT 8
+#define EMAC4SYNC_XAHT_WIDTH_SHIFT 5
+#define EMAC4SYNC_XAHT_BASE_OFFSET 0x80
+
+
+#define EMAC_XAHT_SLOTS(dev) (1 << (dev)->xaht_slots_shift)
+#define EMAC_XAHT_WIDTH(dev) (1 << (dev)->xaht_width_shift)
+#define EMAC_XAHT_REGS(dev) (1 << ((dev)->xaht_slots_shift - \
+ (dev)->xaht_width_shift))
+
+#define EMAC_XAHT_CRC_TO_SLOT(dev, crc) \
+ ((EMAC_XAHT_SLOTS(dev) - 1) - \
+ ((crc) >> ((sizeof (u32) * BITS_PER_BYTE) - \
+ (dev)->xaht_slots_shift)))
+
+#define EMAC_XAHT_SLOT_TO_REG(dev, slot) \
+ ((slot) >> (dev)->xaht_width_shift)
+
+#define EMAC_XAHT_SLOT_TO_MASK(dev, slot) \
+ ((u32)(1 << (EMAC_XAHT_WIDTH(dev) - 1)) >> \
+ ((slot) & (u32)(EMAC_XAHT_WIDTH(dev) - 1)))
+
+static inline u32 *emac_xaht_base(struct emac_instance *dev)
+{
+ struct emac_regs __iomem *p = dev->emacp;
+ int offset;
+
+ if (emac_has_feature(dev, EMAC_FTR_EMAC4SYNC))
+ offset = EMAC4SYNC_XAHT_BASE_OFFSET;
+ else
+ offset = EMAC4_XAHT_BASE_OFFSET;
+
+ return ((u32 *)((ptrdiff_t)p + offset));
+}
+
+static inline u32 *emac_gaht_base(struct emac_instance *dev)
+{
+ /* GAHT registers always come after an identical number of
+ * IAHT registers.
+ */
+ return (emac_xaht_base(dev) + EMAC_XAHT_REGS(dev));
+}
+
+static inline u32 *emac_iaht_base(struct emac_instance *dev)
+{
+ /* IAHT registers always come before an identical number of
+ * GAHT registers.
+ */
+ return (emac_xaht_base(dev));
+}
+
/* Ethtool get_regs complex data.
* We want to get not just EMAC registers, but also MAL, ZMII, RGMII, TAH
@@ -366,4 +440,11 @@ struct emac_ethtool_regs_subhdr {
u32 index;
};
+#define EMAC_ETHTOOL_REGS_VER 0
+#define EMAC_ETHTOOL_REGS_SIZE(dev) ((dev)->rsrc_regs.end - \
+ (dev)->rsrc_regs.start + 1)
+#define EMAC4_ETHTOOL_REGS_VER 1
+#define EMAC4_ETHTOOL_REGS_SIZE(dev) ((dev)->rsrc_regs.end - \
+ (dev)->rsrc_regs.start + 1)
+
#endif /* __IBM_NEWEMAC_CORE_H */
diff --git a/drivers/net/ibm_newemac/debug.c b/drivers/net/ibm_newemac/debug.c
index 86b756a..d9fc0f4 100644
--- a/drivers/net/ibm_newemac/debug.c
+++ b/drivers/net/ibm_newemac/debug.c
@@ -67,29 +67,37 @@ static void emac_desc_dump(struct emac_instance *p)
static void emac_mac_dump(struct emac_instance *dev)
{
struct emac_regs __iomem *p = dev->emacp;
+ const int xaht_regs = EMAC_XAHT_REGS(dev);
+ u32 *gaht_base = emac_gaht_base(dev);
+ u32 *iaht_base = emac_iaht_base(dev);
+ int n;
printk("** EMAC %s registers **\n"
"MR0 = 0x%08x MR1 = 0x%08x TMR0 = 0x%08x TMR1 = 0x%08x\n"
"RMR = 0x%08x ISR = 0x%08x ISER = 0x%08x\n"
- "IAR = %04x%08x VTPID = 0x%04x VTCI = 0x%04x\n"
- "IAHT: 0x%04x 0x%04x 0x%04x 0x%04x "
- "GAHT: 0x%04x 0x%04x 0x%04x 0x%04x\n"
- "LSA = %04x%08x IPGVR = 0x%04x\n"
- "STACR = 0x%08x TRTR = 0x%08x RWMR = 0x%08x\n"
- "OCTX = 0x%08x OCRX = 0x%08x IPCR = 0x%08x\n",
+ "IAR = %04x%08x VTPID = 0x%04x VTCI = 0x%04x\n",
dev->ofdev->node->full_name, in_be32(&p->mr0), in_be32(&p->mr1),
in_be32(&p->tmr0), in_be32(&p->tmr1),
in_be32(&p->rmr), in_be32(&p->isr), in_be32(&p->iser),
in_be32(&p->iahr), in_be32(&p->ialr), in_be32(&p->vtpid),
- in_be32(&p->vtci),
- in_be32(&p->iaht1), in_be32(&p->iaht2), in_be32(&p->iaht3),
- in_be32(&p->iaht4),
- in_be32(&p->gaht1), in_be32(&p->gaht2), in_be32(&p->gaht3),
- in_be32(&p->gaht4),
+ in_be32(&p->vtci)
+ );
+
+ for (n = 0; n < xaht_regs; n++) {
+ printk("IAHT%02d: 0x%08x\n", n + 1, in_be32(iaht_base + n));
+ }
+
+ for (n = 0; n < xaht_regs; n++) {
+ printk("GAHT%02d: 0x%08x\n", n + 1, in_be32(gaht_base + n));
+ }
+
+ printk("LSA = %04x%08x IPGVR = 0x%04x\n"
+ "STACR = 0x%08x TRTR = 0x%08x RWMR = 0x%08x\n"
+ "OCTX = 0x%08x OCRX = 0x%08x IPCR = 0x%08x\n",
in_be32(&p->lsah), in_be32(&p->lsal), in_be32(&p->ipgvr),
in_be32(&p->stacr), in_be32(&p->trtr), in_be32(&p->rwmr),
in_be32(&p->octx), in_be32(&p->ocrx), in_be32(&p->ipcr)
- );
+ );
emac_desc_dump(dev);
}
diff --git a/drivers/net/ibm_newemac/emac.h b/drivers/net/ibm_newemac/emac.h
index 91cb096..a4b5775 100644
--- a/drivers/net/ibm_newemac/emac.h
+++ b/drivers/net/ibm_newemac/emac.h
@@ -41,14 +41,7 @@ struct emac_regs {
u32 vtpid; /* Reset, R, T */
u32 vtci; /* Reset, R, T */
u32 ptr; /* Reset, T */
- u32 iaht1; /* Reset, R */
- u32 iaht2; /* Reset, R */
- u32 iaht3; /* Reset, R */
- u32 iaht4; /* Reset, R */
- u32 gaht1; /* Reset, R */
- u32 gaht2; /* Reset, R */
- u32 gaht3; /* Reset, R */
- u32 gaht4; /* Reset, R */
+ u32 reserved[8];/* Chip-dependent */
u32 lsah;
u32 lsal;
u32 ipgvr; /* Reset, T */
@@ -73,12 +66,6 @@ struct emac_regs {
#define PHY_MODE_RTBI 7
#define PHY_MODE_SGMII 8
-
-#define EMAC_ETHTOOL_REGS_VER 0
-#define EMAC_ETHTOOL_REGS_SIZE (sizeof(struct emac_regs) - sizeof(u32))
-#define EMAC4_ETHTOOL_REGS_VER 1
-#define EMAC4_ETHTOOL_REGS_SIZE sizeof(struct emac_regs)
-
/* EMACx_MR0 */
#define EMAC_MR0_RXI 0x80000000
#define EMAC_MR0_TXI 0x40000000
^ 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