From: "Jon Smirl" <[EMAIL PROTECTED]>
Date: Tue, 22 Jul 2008 19:33:13 -0400
> On 7/22/08, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Jon Smirl" <[EMAIL PROTECTED]>
> >
> > Date: Tue, 22 Jul 2008 18:54:18 -0400
> &
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Sun, 27 Jul 2008 17:52:45 +1000
> On Sat, 2008-07-26 at 23:48 -0700, Roland McGrath wrote:
> > These patches are posted for review, but you can just pull the GIT branch
> > if you prefer. Patch 1/5 corrects a long-standing (minor) error in pt
From: Alan Cox <[EMAIL PROTECTED]>
Date: Sun, 27 Jul 2008 18:27:09 +0100
> On Mon, 28 Jul 2008 02:37:32 +1000
> Stephen Rothwell <[EMAIL PROTECTED]> wrote:
>
> > On powerpc (allyesconfig build) we get this error:
> >
> > drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Sun, 27 Jul 2008 13:33:49 -0700
> > IMHO, this driver was really rushed in and that was a huge mistake.
> > If it had gone through linux-next we could have tidied all of this
> > stuff up in a less "rushed" manner.
>
> ?? This thread *is* about a
More fallout from the premature mISDN driver merge:
drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on
big endian machines now"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Mon, 28 Jul 2008 03:03:04 +0200
> > More fallout from the premature mISDN driver merge:
> >
> > drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not
> > running on big endian machines now"
>
> is that only the HFC driver or the whole
From: Joerg Roedel <[EMAIL PROTECTED]>
Date: Fri, 1 Aug 2008 09:03:28 +0200
> That may be the reason that your fix is not yet upstream.
The reason is more-so because Linus simply hasn't merged more
than a couple of patches since 2.6.27-rc1 was released.
___
From: Grant Likely <[EMAIL PROTECTED]>
Date: Wed, 06 Aug 2008 00:02:44 -0600
> of_lookup_stdout() is useful for figuring out what device to use as output
> for early boot progress messages. It returns the node pointed to by the
> linux,stdout-path property in the chosen node.
>
> Signed-off-by:
From: "Grant Likely" <[EMAIL PROTECTED]>
Date: Wed, 6 Aug 2008 00:35:24 -0600
> On Wed, Aug 6, 2008 at 12:32 AM, David Miller <[EMAIL PROTECTED]> wrote:
> > From: Grant Likely <[EMAIL PROTECTED]>
> > Date: Wed, 06 Aug 2008 00:02:44 -0600
> >
> &
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 6 Aug 2008 17:42:33 +1000
> Hi Grant,
>
> On Wed, 6 Aug 2008 00:34:04 -0600 "Grant Likely" <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
> > <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2008-08-06 at 00:02 -0
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Wed, 6 Aug 2008 20:21:04 +1000
> David Miller writes:
>
> > On sparc platforms this is obtained differently. We obtain the 32-bit
> > instance value of "/chosen/stdout" and convert that into a prom device
>
I just mentioned this to Ben H. on IRC and promised I would report it
here. :-)
The first loop over lmb.memory in this function interprets the
memory_limit as a raw size limit, and that's fine so far.
But the second loop over lmb.reserved interprets this value
instead as an "address limit."
I h
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Thu, 14 Aug 2008 21:26:53 +1000
> Perhaps after the first loop we should set memory_limit to equal
> lmb_end_of_DRAM(), then the second loop should work as it is.
Sounds great. Mind if I push the following to Linus?
lmb: Fix reserved region handl
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Sat, 16 Aug 2008 10:46:22 +1000
> On Fri, 2008-08-15 at 15:25 -0700, David Miller wrote:
> > Sounds great. Mind if I push the following to Linus?
>
> Looks good to me.
>
> I'll test it on Monday. I don'
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Mon, 18 Aug 2008 12:00:32 +1000
> Although I can't find a system with holes (the newer hypervisors make
> things look contiguous I think), so I can't really test the interesting
> case.
I have several so I'll make sure it works in such cases :)
___
I'm working on some drivers for I2C bus support on some of my sparc64
workstations (for lm-sensor and eeprom type devices sitting behind
them) so I went back to trying to get of_i2c.c usable on sparc.
Mostly straightforward stuff _except_ for the I2C address encoding.
What I2C IEEE1275 device bi
sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
This allows more OF layer code to be shared between powerpc and
sparc.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc/include/asm/prom.h |8
arch/sparc/kernel/of_device.c | 11 +++
a
of_i2c: Add sparc support.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/of/Kconfig |2 +-
drivers/of/of_i2c.c | 58 --
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
of: Add some I2C mod aliases table entries for sparc64 systems.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/of/base.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..e849f69 100644
--- a/drivers/o
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 07:50:20 -0500
> Fix warnings of the form:
> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized
> in this function
> arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized
> in this function
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 07:50:21 -0500
> Some architectures (like powerpc) provide status information on the exact
> type of invalid exception. This is pretty straight forward as we already
> report invalid exceptions via FP_SET_EXCEPTION.
>
> We add new flags
From: Scott Wood <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 11:32:56 -0500
> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Miller wrote:
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> >giving it to the Linux I2C layer.
>
> Maybe w
From: Scott Wood <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 16:35:02 -0500
> David Miller wrote:
> > If you guys created this format in your compressed openfirmware
> > trees, is it possible for you to "fix" it to match what Sparc
> > systems following
From: "Jon Smirl" <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 17:53:02 -0400
> > 2) When CONFIG_SPARC, shift the device address down by one bit before
> >giving it to the Linux I2C layer.
>
> How do you deal with a 10-bit address i2c device? Is it multiplied by two too?
Yes.
From: Anton Vorontsov <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 01:56:11 +0400
> On Thu, Aug 21, 2008 at 12:10:17AM -0700, David Miller wrote:
> > @@ -96,6 +96,14 @@ static inline void of_node_put(struct device_node *node)
> > {
> > }
> >
> >
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 08:05:50 +1000
> On Thu, 2008-08-21 at 14:45 -0700, David Miller wrote:
> > > As far as I can tell from poking around
> > > http://penguinppc.org/historical/dev-trees-html/, they don't inclu
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 08:05:02 +1000
> Apple additionally have different ways of representing multiple busses
> on one controller though. On some machines, they just use bits 0xF00 of
> the address as the bus number, which is a bit gross, and on so
From: "Grant Likely" <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 16:52:32 -0600
> On Thu, Aug 21, 2008 at 1:10 AM, David Miller <[EMAIL PROTECTED]> wrote:
> >
> > of: Add some I2C mod aliases table entries for sparc64 systems.
> >
> > Signed-off
From: "Grant Likely" <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 17:14:57 -0600
> On Thu, Aug 21, 2008 at 3:35 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> > David Miller wrote:
> >>>
> >>> On Thu, Aug 21, 2008 at 12:10:12AM -0700, David Mil
From: Josh Boyer <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 21:15:37 -0400
> Huge? I'd say mistake, but not necessarily huge. I mean nobody other
> than you (at least in the context of this conversation) had access to
> the IEEE1275 proposed binding so it wasn't like there was tons to go on.
I
Ok, I've integrated the feedback I got from various reviewers and for
now I'm going to handle the sparc vs. powerpc aspects with a helper
asm/of_i2c.h header file that implements the address fetching.
I think for the time being this is the best solution. If the
semantics converge, we can merge t
sparc: Implement irq_of_parse_and_map() and irq_dispose_mapping().
This allows more OF layer code to be shared between powerpc and
sparc.
With feedback and suggestions from Anton Vorontsov.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc/include/asm/prom.h | 10 ++
of_i2c: Add Sparc support.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
arch/sparc/include/asm/of_i2c.h | 67 +++
drivers/of/Kconfig |2 +-
2 files changed, 68 insertions(+), 1 deletions(-)
create mode 100644 arch/sparc/include/as
of_i2c: Abstract out register property interpretation.
Pull out client I2C device address calculation into a
helper function, of_i2c_fetch_addr.
At the top level we try to determine the reported
#address-cells property in the I2C bus adapter node,
and default to "1" if the property is not found.
From: "Grant Likely" <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 22:18:56 -0600
> On Thu, Aug 21, 2008 at 9:53 PM, David Miller <[EMAIL PROTECTED]> wrote:
> >> Have patience with the embedded people that are both new to
> >> OpenFirmware and try
From: "Grant Likely" <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 22:34:31 -0600
> On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley <[EMAIL PROTECTED]> wrote:
> >> Hi, I wrote most of 1275.
> >>
> >> Mitch Bradley ([EMAI
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 21:21:45 -0700 (PDT)
> of_i2c: Add Sparc support.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Of course, after testing, I noticed that I forgot the all
important shifts here. :-)
Here is a fixed patc
From: Josh Boyer <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 06:50:48 -0400
> On Thu, 21 Aug 2008 20:53:05 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Josh Boyer <[EMAIL PROTECTED]>
> > Date: Thu, 21 Aug 2008 21:15:37 -0400
>
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Fri, 29 Aug 2008 15:40:36 +1000
> The main remaining substantial technical issue is how we detect very
> early on that we are a kdump kernel. I think the policy should be
> that the kernel copies itself down to 0 if it's not a kdump kernel and
> runs
I'm not really interested in this dicussion, the states make sense
to me and I know how I will use them.
I'm also extremely backlogged as-is, and this will only compound
things.
Therefore, please drop me from the CC: list, thanks.
___
Linuxppc-dev mail
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Fri, 19 Sep 2008 15:59:32 -0700
> [BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't
> explicitly remove you. Presumably you are getting this thread through
> the linuxppc-dev list.]
Indeed, my bad :)
From: Andy Fleming <[EMAIL PROTECTED]>
Date: Mon, 13 Oct 2008 13:04:30 -0500
>
> On Oct 13, 2008, at 12:19, Adrian Bunk wrote:
>
> > This patch fixes the following build error caused by
> > commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
> > (mv643xx_eth: convert to phylib):
> >
> > <-- snip -
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Mon, 13 Oct 2008 20:19:00 +0300
> This patch fixes the following build error caused by
> commit ed94493fb38a665cebcf750dfabe8a6dd13e136f
> (mv643xx_eth: convert to phylib):
Applied, th anks Adrian.
___
Linuxpp
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 15 Oct 2008 21:33:37 -0700
> kernel/resource.c: In function '__reserve_region_with_split':
> kernel/resource.c:554: warning: format '%llx' expects type 'long long
> unsigned int', but argument 3 has type 'resource_size_t'
> kernel/resource.c:554:
From: Brice Goglin <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 08:55:08 +0200
> Dan Williams wrote:
> > On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> >
> >>> drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
> >>> dr
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
> On Wed, 15 Oct 2008, David Miller wrote:
> > > kernel/resource.c: In function '__reserve_region_with_split':
> > > kernel/resource.c:554: warning: format '%llx&#x
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 11:09:30 -0500
>
> On Oct 16, 2008, at 6:13 AM, Wolfram Sang wrote:
>
> >
> > Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove
> > automatic probing for this i2c controller. Might need updates to dts files
> > usi
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 16:57:19 +0200
> On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
> >
> >
> > > net/sched/sch_generic.c: In function 'dev_watchdog':
> > > net/sched/sch_generic.c:224: warning
From: Anton Vorontsov <[EMAIL PROTECTED]>
Date: Thu, 16 Oct 2008 21:12:51 +0400
> The name of the device_node field differ across the platforms, so we
> have to implement inlined accessors. This is needed to avoid ugly
> #ifdef in the generic code.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTE
From: "Brandeburg, Jesse" <[EMAIL PROTECTED]>
Date: Thu, 23 Oct 2008 14:50:06 -0700
> Chris Friesen wrote:
> > I tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very
> > similar to a Maple board). The first time I booted I got the first
> > log below via the serial console. I rebooted a
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 10:57:38 -0500
> Commit 18404756765c713a0be4eb1082920c04822ce588 introduced a regression
> on a subset of SMP based PPC systems whose interrupt controller only
> allow setting an irq to a single processor. The previous behavior
> was onl
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 10:39:05 -0500
> As for making it ARCH specific, that doesn't really help since not
> all PPC hw has the limitation I spoke of. Not even all MPIC (in our
> cases) have the limitation.
Since the PPC code knows exactly which MPICs have th
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 17:39:00 -0600
> So...it would appear that the NAPI code is somehow buggy, and
> 6ba33ac should probably be reverted until the problem is found and
> fixed.
No I think the problem is simple enough that someone should study the
->pol
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Fri, 24 Oct 2008 23:42:48 -0600
> David Miller wrote:
> > From: "Chris Friesen" <[EMAIL PROTECTED]>
> > Date: Fri, 24 Oct 2008 17:39:00 -0600
> >
> >> So...it would appear that the N
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Sun, 26 Oct 2008 08:33:09 +1100
> Well, I don't know how you do it but on powerpc, we explicitely fill the
> affinity masks at boot time when we can spread interrupts... Maybe we
> should change it the other way around and limit the mask when
From: Kevin Diggs <[EMAIL PROTECTED]>
Date: Sat, 25 Oct 2008 15:53:46 -0700
> What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
> thing supposed to be able to spread irq between its cpus?
Networking interrupts should lock onto a single CPU, unconditionally.
That's the optimal way t
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Sun, 26 Oct 2008 17:48:43 +1100
>
> > What does this all mean to my GigE (dual 1.1 GHz 7455s)? Is this
> > thing supposed to be able to spread irq between its cpus?
>
> Depends on the interrupt controller. I don't know that machine
> but for
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 11:36:21 -0600
> David Miller wrote:
> > From: Kevin Diggs <[EMAIL PROTECTED]>
> > Date: Sat, 25 Oct 2008 15:53:46 -0700
> >
> >> What does this all mean to my GigE (dual 1.1 G
From: "Chris Friesen" <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 13:10:55 -0600
> David Miller wrote:
> > From: "Chris Friesen" <[EMAIL PROTECTED]>
>
> > Hello, we either have hardware that does flow seperation and has multiple
> > RX
From: Kumar Gala <[EMAIL PROTECTED]>
Date: Mon, 27 Oct 2008 14:43:29 -0500
> I haven't been following the netdev patches, but what about HW that does flow
> separation w/o multiple interrupts?
>
> We (Freescale) are working on such a device:
>
> http://www.freescale.com/webapp/sps/site/prod_sum
is patch is basically as suggested by David Miller.
>
> Signed-off-by: Chris Friesen <[EMAIL PROTECTED]>
I had to apply this by hand because your email client heavily
corrupted the patch.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Thu, 13 Nov 2008 15:20:35 +1100 (EST)
> + np = from ? from->allnext : allnodes;
> + for (; np; np = np->allnext) {
> + for (pp = np->properties; pp != 0; pp = pp->next) {
> + if (of_prop_cmp(pp->name, prop_nam
From: Michael Ellerman <[EMAIL PROTECTED]>
Date: Thu, 13 Nov 2008 18:11:43 +1100
> With my compiler (4.3.1) it just gets inlined and actually makes the
> text 8 bytes larger. We might be using different CFLAGs to sparc though.
>
> I didn't think it made the source significantly clearer to split o
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Tue, 18 Nov 2008 13:36:16 +1100
> Steven Rostedt writes:
>
> > By-the-way, my box has been running stable ever since I switched to
> > CONFIG_IRQSTACKS.
>
> Great. We probably should remove the config option and just always
> use irq stacks.
That
From: Neil Horman
Date: Mon, 29 Dec 2008 10:37:57 -0500
> On Mon, Dec 29, 2008 at 09:41:44PM +1100, Stephen Rothwell wrote:
> > Hi Kamalesh,
> >
> > On Mon, 29 Dec 2008 15:55:29 +0530 Kamalesh Babulal
> > wrote:
> > > greping through the sources for the changes missed out, we have
> > >
> >
From: Stephen Rothwell
Date: Wed, 31 Dec 2008 14:02:25 +1100
> These variables are only used with an interface involving "unsigned
> long" and the macros are only used with these variables. This change
> will prevent some warnings when we change u64 to "unsigned long long".
>
> This code is onl
From: Stephen Rothwell
Date: Wed, 31 Dec 2008 14:17:30 +1100
> ehea_plpar_hcall9() takes an unsigned long array, so pass that.
>
> This change will avoid some warnings when we change u64 to unsigned
> long long.
>
> Signed-off-by: Stephen Rothwell
Patch rejected, for the same reasons as the o
From: Stephen Rothwell
Date: Wed, 31 Dec 2008 14:18:53 +1100
> These changes will avoid several warnings when we change u64 to unsigned
> long long.
>
> Also, ehea_driver_flags is only used in ehca_main.c
>
> Signed-off-by: Stephen Rothwell
> ---
And also rejected, just like the previous two.
From: Stephen Rothwell
Date: Tue, 6 Jan 2009 10:59:51 +1100
> Hi Dave,
>
> On Tue, 30 Dec 2008 21:51:56 -0800 (PST) David Miller
> wrote:
> >
> > From: Stephen Rothwell
> > Date: Wed, 31 Dec 2008 14:18:53 +1100
> >
> > > These changes will
From: Stephen Rothwell
Date: Tue, 6 Jan 2009 11:05:11 +1100
> Hi Dave,
>
> On Wed, 31 Dec 2008 20:09:01 +1100 Benjamin Herrenschmidt
> wrote:
> >
> > Well, in that case, this patch is actually correct without considering
> > the u64 change. The array is what lands in the registers of the pHyp
From: Ben Warren
Date: Mon, 05 Jan 2009 17:27:06 -0800
> I expect they're all people, like myself, that have been bumped here
> from the ppc_embedded list and aren't used to all the traffic.
This is why, as a policy, we never allow propagation of subscribers
from old lists to new ones created at
From: "Jeff Brower"
Date: Mon, 5 Jan 2009 20:28:46 -0600 (CST)
> I completely disagree. I'm glad the embedded PC list owners were
> thoughtful enough to migrate me to the new list.
At the very least I know that all of the folks asking to
be unsubscribed would likely take my side on this one :-)
From: Stephen Rothwell
Date: Tue, 6 Jan 2009 16:34:54 +1100
> ehea_plpar_hcall9() takes an "unsigned long" array to return its results,
> so change the arrays we pass to it to match. This is currently only
> 64 bit code, so the transformation is actually a noop, but because
> ehea_plpar_hcall9()
From: Stephen Rothwell
Date: Tue, 6 Jan 2009 16:39:08 +1100
> These variables are only used with an interface that just dumps their
> values into registers to be passed to the hypervisor. The arguments
> to that interface are declared to be "unsigned long", so make these
> variables match. The m
From: Andy Fleming
Date: Tue, 6 Jan 2009 14:56:25 -0600
>
> On Jan 6, 2009, at 2:52 PM, Kumar Gala wrote:
>
> > From: Leo Li
> >
> > When changing the link between 100Mbps and 1Gbps in SGMII mode it was
> > found out that the link would stop working. The issue is that ECNTRL[R100]
> > needs t
From: Stephen Rothwell
Date: Wed, 7 Jan 2009 11:40:06 +1100
> These are powerpc specific drivers.
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/net/ehea/ehea_main.c |8
> drivers/net/ehea/ehea_qmr.c | 18 +-
> drivers/net/ibmveth.c| 16 --
From: Kumar Gala
Date: Wed, 7 Jan 2009 09:52:01 -0600
> Commit b31a1d8b41513b96e9c7ec2f68c5734cef0b26a4 went back to using
> BUS_ID_SIZE instead of sizeof() as per the larger patch series
> that will remove "char bus_id[20]" from struct device.
>
> Signed-off-by: Kumar Gala
Applied, thanks Ku
From: Ira Snyder
Date: Wed, 7 Jan 2009 11:50:52 -0800
> This adds support to Linux for a virtual ethernet interface which uses the
> PCI bus as its transport mechanism. It creates a simple, familiar, and fast
> method of communication for two devices connected by a PCI interface.
Well, it looks
From: "Timur Tabi"
Date: Wed, 7 Jan 2009 14:17:04 -0600
> On Wed, Jan 7, 2009 at 2:12 PM, Timur Tabi wrote:
>
> > This patch will break ucc_geth.c if my other patch, "powerpc: add Ethernet
> > UPSMR definitions to QE library" isn't also applied. That patch is
> > currently
> > in Kumar's 'nex
From: Timur Tabi
Date: Wed, 7 Jan 2009 14:12:52 -0600
> The UCC Event Register (UCCE) already has unambigous macro definitions in
> qe.h,
> so we should not be defining our own in the UCC Ethernet driver.
>
> Removed unused local variable 'dev' from ucc_geth_poll(), which fixes a
> warning
>
From: Anton Vorontsov
Date: Mon, 12 Jan 2009 21:38:35 +0300
> This patch fixes following bug:
>
> BUG: soft lockup - CPU#0 stuck for 61s! [S03mountvirtfs-:922]
...
> Signed-off-by: Anton Vorontsov
Applied, thanks Anton.
___
Linuxppc-dev mailing list
From: Andy Fleming
Date: Wed, 14 Jan 2009 12:20:35 -0600
> On Jan 14, 2009, at 9:03 AM, Anton Vorontsov wrote:
> >>
> >> There is one thing I don't actually understand though...
> >>
> >> Andy, were you testing the TBI support on a hardware where PHY ID
> >> != 0x0 or maybe your TBI PHY support p
From: Kumar Gala
Date: Tue, 13 Jan 2009 10:28:15 -0600
>
> On Oct 27, 2008, at 4:46 PM, Mike Ditto wrote:
>
> > If something goes wrong attaching to phy driver, we weren't freeing
> > the IRQ.
> >
> > Signed-off-by: Mike Ditto
...
> This seems to have gotten lost in the shuffle. Can you plea
From: Geert Uytterhoeven
Date: Wed, 14 Jan 2009 11:00:05 +0100 (CET)
> On Wed, 14 Jan 2009, Benjamin Herrenschmidt wrote:
> > This adds an init_dummy_netdev() function that gets a network device
> > structure (allocation and lifetime entirely under caller's control) and
> > initialize the minimum
From: Michael Ellerman
Date: Thu, 15 Jan 2009 17:46:01 +1100 (EST)
> The lmb debugging can be turned on at boottime with lmb=debug on the
> command line. However on powerpc that doesn't work, because we don't
> necessarily call lmb_dump_all().
>
> So always call lmb_dump_all() after lmb_analyze(
From: Michael Ellerman
Date: Thu, 15 Jan 2009 17:46:02 +1100 (EST)
> The lmb_dump_all() output didn't include the RMO size, which is
> interesting on powerpc. The output was also a bit spacey and not well
> aligned, and didn't show you the end addresses.
>
> Signed-off-by: Michael Ellerman
Ack
I've applied both of your conversion patches, thank you.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:00 +0100
> Adapt to lately introduced net_device_ops structure.
>
> Signed-off-by: Thomas Klein
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxpp
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:20 +0100
> PAGE_SIZE allocations via slab are not guaranteed to be page-aligned. Fixed
> all memory allocations where page alignment is required by firmware.
>
> Signed-off-by: Thomas Klein
Applied.
___
From: Thomas Klein
Date: Wed, 21 Jan 2009 15:49:41 +0100
> Reworked receive queue fill policies to make the driver more tolerant
> in low memory conditions.
>
> Signed-off-by: Thomas Klein
Applied, but there is an even better way to handle this.
You should be allocating replacement RX skbs at
Paul, I just noticed that right now if perf counter is enabled, the
oprofile module load will always fail because the powerpc perf counter
support unconditionally grabs the PMC hardware using
reserve_pmc_hardware() in an arch_initcall()
There really needs to be a way to segregate these multiple u
From: Paul Mackerras
Date: Thu, 22 Jan 2009 18:06:13 +1100
> Out of curiosity, what ppc hardware are you using perf_counters on?
> A G5?
An UltraSPARC-IIIi :-)
I just wanted to make sure you realized the conflict, and you
obviously do.
___
Linuxppc-de
From: Anton Vorontsov
Date: Thu, 22 Jan 2009 21:09:30 +0300
> Suspend/resume routines check for phydrv != NULL, but that is
> wrong because "phydrv" comes from container_of(drv). If drv is NULL,
> then container_of(drv) will return non-NULL result, and the checks
> won't work.
>
> The Freescale
From: Andy Fleming
Date: Mon, 26 Jan 2009 15:07:37 -0600
>
> On Jan 26, 2009, at 2:50 PM, Anton Vorontsov wrote:
>
> > commit 77ecaf2d5a8bfd548eed3f05c1c2e6573d5de4ba ("gianfar: Fix VLAN
> > HW feature related frame/buffer size calculation") wrongly removed
> > priv->vlgrp assignment, and now p
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 13 Jul 2007 15:05:15 -0500
>
> This is a patch (& bug report) for a crash in sysctl_set_parent()
> in 2.6.22-git2.
>
> Problem: 2.6.22-git2 crashes with a stack trace
> [c1d0fb00] c0067b4c .sysctl_set_parent+0x48/0x7c
> [c
I think this work is great. Thanks for doing it.
Besides the fixups Evgeniy has selected, and the suggestion
to receive into pages to cut down allocation costs, my
only request is to make this thing able to handle ipv6 as
well even if no current chips could facilitate that yet.
_
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Sun, 15 Jul 2007 10:12:53 +0100
> I'm not sure that's a good idea. If current chips can't handle ipv6
> lro there is no way to actually test it and the code will surely bitrot.
Christoph, you can do LRO pretty much completely in software.
__
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Mon, 16 Jul 2007 12:25:35 -0500
> On Fri, Jul 13, 2007 at 03:47:02PM -0700, David Miller wrote:
> > From: [EMAIL PROTECTED] (Linas Vepstas)
> > Date: Fri, 13 Jul 2007 15:05:15 -0500
> >
> > >
> > > This i
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 18 Jul 2007 17:30:24 +1000
> Hi Dave, Paul,
>
> The latest version of the changes is available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sfr/ofcons.git master
>
> I will send patches to the lists if people
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Wed, 18 Jul 2007 15:00:59 +0200
> Hi,
>
> I suggest we keep the interface open for IPv6 support by adding
> an additional parameter but first just get IPv4 support only
> into the kernel. IPv6 support can then incrementially be added.
> Would th
701 - 800 of 1000 matches
Mail list logo
