On Tue, Aug 07, 2007 at 04:22:31PM +1000, David Gibson wrote:
> This driver is designed to sit alongside the old driver (it lies in
> drivers/net/ibm_emac and this one in drivers/net/ibm_newemac). The
> old driver is left in place to support arch/ppc until arch/ppc itself
> reaches its final demi
Hi Andrew,
I got the following errors when building 2.6.23-rc2-mm2 on both mips and
arm. Both errors are very much alike.
MIPS:
/opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/3.4.5/include
-D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-
Hi All,
In order to debug the 8548 CDS BSP of kernel 2.6, I want setup serial port
with UART on mpc85xx as early as possible. . I add the register access
code at the beginning of platform_init(). However the system just hanging
there with this line. If I comment out this
line"WRITE8_ADDR(M85xx_EI
Hi All,
In order to debug the kernel 2.6, I want setup serial port with UART on
mpc85xx as early as possible. I add the register access code at the
beginning of platform_init(). For example, I try to write THR
register(0xe0004500). However the system just hanging there with this line.
If I commen
Paul Mackerras wrote:
> David Gibson writes:
>
>> We decided that since a formal dtc release was imminent, it would be
>> simpler to make dtc a new kernel build requirement, rather than
>> integrate the substantial blob of dtc code into the kernel tree and
>> then have to deal with the maintenance
David Gibson writes:
> We decided that since a formal dtc release was imminent, it would be
> simpler to make dtc a new kernel build requirement, rather than
> integrate the substantial blob of dtc code into the kernel tree and
> then have to deal with the maintenance / synchronization issues
> be
Segher Boessenkool writes:
> Instead, use asm() like all other atomic operations already do.
>
> Also use inline functions instead of macros; this actually
> improves code generation (some code becomes a little smaller,
> probably because of improved alias information -- just a few
> hundred byte
Instead, use asm() like all other atomic operations already do.
Also use inline functions instead of macros; this actually
improves code generation (some code becomes a little smaller,
probably because of improved alias information -- just a few
hundred bytes total on a default kernel build, nothi
>>> We decided that since a formal dtc release was imminent, it would be
>>> simpler to make dtc a new kernel build requirement,
>>
>> For _all_ kernel builds? Most people building a powerpc
>> kernel don't need it.
>
> The dtc is run from the wrapper script, so if you build for a platform
> that
Segher Boessenkool wrote:
Actually, after discussions with Stephen and Paulus, we decided not
to
take this route. In any case having Kbuild like versioning wouldn't
actually help us any in integrating into a full Kbuild system.
>>>
>>> Can you elaborate why you decided not to?
On Thu, Aug 09, Jon Loeliger wrote:
> As usual, please let me know of any issues with it.
tests/truncated_property.c:45: warning: 'err' is used uninitialized in this
function
(untested patch)
---
tests/truncated_property.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/test
>>> Actually, after discussions with Stephen and Paulus, we decided not
>>> to
>>> take this route. In any case having Kbuild like versioning wouldn't
>>> actually help us any in integrating into a full Kbuild system.
>>
>> Can you elaborate why you decided not to? I'm just curious.
>
> We decid
> Why is "ranges" conceptually wrong?
The flash partitions aren't separate devices sitting on a
"flash bus", they are "sub-devices" of their parent.
>>>
>>> Well, yes, but nonetheless the partitions show up as part of the
>>> overall physical address space. How do you encode tha
>>> We should co-ordinate better on this, if it's to become a
>>> convention...
>>
>> That means we shouldn't coordinate on this, right?
>
> Heh. Either one is kind of ugly, I'll grant you.
>
> But, many SoCs do have a notion of device "number", which is relevant
> for programming other general co
> * In drivers/net/ibm_newemac/Makefile, I think the preferred method is
>to use ibm_newemac-y rather than ibm_newemac-objs.
I thought it was the other way around, so I checked with the
Kbuild maintainer, and indeed you are correct.
Segher
___
Li
>>> It seems that some versions of firmware will report a device
>>> node status as the string "okay". As we are not expecting this
>>> string, the device node will be ignored by the EEH subsystem.
>>> Which means EEH will not be enabled.
>>>
>>> When EEH is not enabled, PCI errors will be converte
Removes dead frag processing code from ibmveth. Since NETIF_F_SG was
not set, this code was never executed. Also, since the ibmveth
interface can only handle 6 fragments, core networking code would need
to be modified in order to efficiently enable this support.
Signed-off-by: Brian King <[EMAIL
Removes the use of bitfields from the ibmveth driver. This results
in slightly smaller object code.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 90
linux-2.6-bjking1/drivers/net/ibmveth.h | 56 -
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 51
1 file changed, 51 insertions(+)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats
drivers/
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c |2 ++
1 file changed, 2 insertions(+)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 125 +++-
linux-2.6-bjking1/drivers/net/ibmveth
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yield
Segher Boessenkool wrote:
>> It seems that some versions of firmware will report a device
>> node status as the string "okay". As we are not expecting this
>> string, the device node will be ignored by the EEH subsystem.
>> Which means EEH will not be enabled.
>>
>> When EEH is not enabled, PCI er
> It seems that some versions of firmware will report a device
> node status as the string "okay". As we are not expecting this
> string, the device node will be ignored by the EEH subsystem.
> Which means EEH will not be enabled.
>
> When EEH is not enabled, PCI errors will be converted into
> Mac
>>> Well, I had already checked with Ben, who wrote the code, and my
>>> understanding is that the reads are intended to work around some
>>> misbehaving Apple bridges,
>>
>> None of the PCI interfaces on the U3 or U4 bridges have that
>> problem as far as I know. I think the workaround was copied
> hm... Well, the worst that could happen, if an "evil" programmer
> defines
> too long a name, it gets truncated, and then binds to a wrong driver,
> well, the worst that can happen is that your hardware gets damaged,
> not a
> big thing.
:-)
> However, some might disagree, so, below is a new
Soohyung Cho wrote:
>>+void fsl_sleep_device(struct fsl_sleep_platform_data *data) {
>>+ if (clock_regs && data->sccr_mask) {
>>+ unsigned long flags;
>>+ u32 sccr;
>
>
> Your && operation between clock_regs and sccr_mask seems to be a little bit
> mistake,
> cause typ
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of bug-fixes for powerpc. I have included the
full log messages this time. The changes for spu_base.c and
spu_manage.c are mostly code movement that was needed so that a
PS3-
28 matches
Mail list logo
