> 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
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
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
>>> 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
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
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/
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 -
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
> * 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
>>> 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
> 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
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
--
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
>>> 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
>>> 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
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-
> 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
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?
>>> 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
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
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
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
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
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
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 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-
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
28 matches
Mail list logo
