* Re: [PATCH][MIPS] AR7 ethernet
From: Jeff Garzik @ 2007-10-15 18:24 UTC (permalink / raw)
To: Matteo Croce
Cc: linux-mips, Eugene Konev, netdev, davem, kuznet, pekkas, jmorris,
yoshfuji, kaber, Andrew Morton
In-Reply-To: <200710141810.13752.technoboy85@gmail.com>
applied
^ permalink raw reply
* Re: [PATCH 1/5] myri10ge: fix some indentation, white spaces, and comments
From: Jeff Garzik @ 2007-10-15 18:24 UTC (permalink / raw)
To: Brice Goglin; +Cc: netdev
In-Reply-To: <47109EB5.6060801@myri.com>
Brice Goglin wrote:
> Fix one comment in myri10ge.c and update indendation and white spaces
> to match the code generated by indent from upstream CVS.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> ---
> drivers/net/myri10ge/myri10ge.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
applied 1-5
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:27 UTC (permalink / raw)
To: Valentine Barshak, jwboyer, Michael Ellerman; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071015175717.GA4602@ru.mvista.com>
Valentine Barshak wrote:
> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> These PHY chips are used on PowerPC 440EPx boards.
> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 files changed, 39 insertions(+)
>
> --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> @@ -306,8 +306,47 @@
> .ops = &cis8201_phy_ops
> };
>
> +static struct mii_phy_def bcm5248_phy_def = {
> +
> + .phy_id = 0x0143bc00,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "BCM5248 10/100 SMII Ethernet",
> + .ops = &generic_phy_ops
> +};
> +
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> + phy_write(phy, 0x14, 0x0ce3);
> + phy_write(phy, 0x18, 0x4101);
> + phy_write(phy, 0x09, 0x0e00);
> + phy_write(phy, 0x04, 0x01e1);
> + phy_write(phy, 0x00, 0x9140);
> + phy_write(phy, 0x00, 0x1140);
> +
> + return 0;
> +}
> +
> +static struct mii_phy_ops m88e1111_phy_ops = {
> + .init = m88e1111_init,
> + .setup_aneg = genmii_setup_aneg,
> + .setup_forced = genmii_setup_forced,
> + .poll_link = genmii_poll_link,
> + .read_link = genmii_read_link
> +};
> +
> +static struct mii_phy_def m88e1111_phy_def = {
> +
> + .phy_id = 0x01410CC0,
> + .phy_id_mask = 0x0ffffff0,
> + .name = "Marvell 88E1111 Ethernet",
> + .ops = &m88e1111_phy_ops,
> +};
> +
> static struct mii_phy_def *mii_phy_table[] = {
> &cis8201_phy_def,
> + &bcm5248_phy_def,
> + &m88e1111_phy_def,
> &genmii_phy_def,
Seems sane to me -- ACK -- but we have multiple people sending me
patches for a single driver. That's normal for janitorial cleanups
across the whole tree, but discouraged when multiple people are actively
working on the same driver.
Please coordinate, and have ONE person send me patches...
^ permalink raw reply
* Re: [PATCH] forcedeth: Fix MAC address detection on network card (regression in 2.6.23)
From: Jeff Garzik @ 2007-10-15 18:33 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Michael Pyne, Andrew Morton, netdev
In-Reply-To: <200710112242.50167.michael.pyne@kdemail.net>
Michael Pyne wrote:
> Partially revert a change to mac address detection introduced to the forcedeth
> driver. The change was intended to correct mac address detection for newer
> nVidia chipsets where the mac address was stored in reverse order. One of
> those chipsets appears to still have the mac address in reverse order (or at
> least, it does on my system).
>
> Signed-off-by: Michael J. Pyne <michael.pyne@kdemail.net>
> ---
> The change that broke mac address detection for my card was commit
> ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
>
> My network card is an nVidia built-in Ethernet card, output from lspci as
> follows (with text and numeric ids):
> $ lspci | grep Ethernet
> 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
> $ lspci -n | grep 07.0
> 00:07.0 0680: 10de:03ef (rev a2)
>
> The vendor id is, of course, nVidia. The device id corresponds to the
> NVIDIA_NVENET_19 entry.
>
> The included patch fixes the MAC address detection on my system.
> Interestingly, the MAC address appears to be in the range reserved for my
> motherboard manufacturer (Gigabyte) and not nVidia.
>
> If you need any further information about my hardware configuration just let
> me know.
>
> Regards,
> - Michael Pyne
>
> --- a/drivers/net/forcedeth.c 2007-10-11 22:01:26 -0400
> +++ b/drivers/net/forcedeth-new.c 2007-10-11 22:06:52 -0400
> @@ -5513,7 +5513,7 @@ static struct pci_device_id pci_tbl[] =
> },
> { /* MCP61 Ethernet Controller */
> PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_19),
> - .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|
> DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|
> DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
> + .driver_data = DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|
> DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|
> DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
> },
> { /* MCP65 Ethernet Controller */
> PCI_DEVICE(PCI_VENDOR_ID_NVIDIA, PCI_DEVICE_ID_NVIDIA_NVENET_20),
your patch is word-wrapped. Anyway...
Ayaz -- ACK this patch?
^ permalink raw reply
* Re: [NET] SAA9730: Fix build
From: Jeff Garzik @ 2007-10-15 18:33 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Andrew Morton, netdev
In-Reply-To: <20071014131358.GA19955@linux-mips.org>
Ralf Baechle wrote:
> Fix build breakage by the recent statistics cleanup in cset
> 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
applied
^ permalink raw reply
* Re: [NET] TC35815: Fix build
From: Jeff Garzik @ 2007-10-15 18:33 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Andrew Morton, netdev, Stephen Hemminger, Atsushi Nemoto
In-Reply-To: <20071014134026.GA30056@linux-mips.org>
Ralf Baechle wrote:
> bea3348eef27e6044b6161fd04c3152215f96411 broke the build of tc35815.c
> for the non-NAPI case:
>
> CC drivers/net/tc35815.o
> drivers/net/tc35815.c: In function 'tc35815_interrupt':
> drivers/net/tc35815.c:1464: error: redefinition of 'lp'
> drivers/net/tc35815.c:1443: error: previous definition of 'lp' was here
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
applied
^ permalink raw reply
* Re: [PATCH] tehuti: possible leak in bdx_probe
From: Jeff Garzik @ 2007-10-15 18:34 UTC (permalink / raw)
To: Florin Malita; +Cc: baum, andy, Andrew Morton, netdev
In-Reply-To: <4710FA6A.2070902@gmail.com>
Florin Malita wrote:
> If pci_enable_device fails, bdx_probe returns without freeing the
> allocated pci_nic structure.
>
> Coverity CID 1908.
>
> Signed-off-by: Florin Malita <fmalita@gmail.com>
> ---
>
> drivers/net/tehuti.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
applied
^ permalink raw reply
* Re: [NET] Jazzsonic: Fix warning about unused variable.
From: Jeff Garzik @ 2007-10-15 18:34 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Andrew Morton, netdev, Thomas Bogendoerfer
In-Reply-To: <20071015095840.GA30451@linux-mips.org>
Ralf Baechle wrote:
> Caused by "[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()"
> aka 0795af5729b18218767fab27c44b1384f72dc9ad.
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
applied
^ permalink raw reply
* Re: [NET] MIPSsim: General cleanup
From: Jeff Garzik @ 2007-10-15 18:34 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Andrew Morton, netdev
In-Reply-To: <20071012135956.GA16163@linux-mips.org>
Ralf Baechle wrote:
> General cleanups mostly as suggested by checkpatch plus getting rid of
> homebrew version of offsetof().
>
> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
applied
^ permalink raw reply
* Re: [PATCH 1/6] Convert bonding timers to workqueues
From: Jeff Garzik @ 2007-10-15 18:41 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev, andy
In-Reply-To: <11920760502756-git-send-email-fubar@us.ibm.com>
Jay Vosburgh wrote:
> Convert bonding timers to workqueues. This converts the various
> monitor functions to run in periodic work queues instead of timers. This
> patch introduces the framework and convers the calls, but does not resolve
> various locking issues, and does not stand alone.
>
> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
"does not stand alone" == it is not bisectable? That's a problem.
Anyway, we have more fun fish to fry: after applying the IPoIB bonding
patchset, this no longer applies...
^ permalink raw reply
* Re: [PATCH] gianfar: Cleanup compile warning caused by 0795af57
From: Jeff Garzik @ 2007-10-15 18:41 UTC (permalink / raw)
To: Li Yang; +Cc: netdev
In-Reply-To: <1192197233-24958-3-git-send-email-leoli@freescale.com>
Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> drivers/net/gianfar.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
applied all three gianfar patches
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 18:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Valentine Barshak, Michael Ellerman, linuxppc-dev, netdev
In-Reply-To: <4713B10B.5000607@garzik.org>
On Mon, 15 Oct 2007 14:27:23 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Valentine Barshak wrote:
> > This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
> > These PHY chips are used on PowerPC 440EPx boards.
> > The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> > drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 39 insertions(+)
> >
> > --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
> > +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
> > @@ -306,8 +306,47 @@
> > .ops = &cis8201_phy_ops
> > };
> >
> > +static struct mii_phy_def bcm5248_phy_def = {
> > +
> > + .phy_id = 0x0143bc00,
> > + .phy_id_mask = 0x0ffffff0,
> > + .name = "BCM5248 10/100 SMII Ethernet",
> > + .ops = &generic_phy_ops
> > +};
> > +
> > +static int m88e1111_init(struct mii_phy *phy)
> > +{
> > + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
> > + phy_write(phy, 0x14, 0x0ce3);
> > + phy_write(phy, 0x18, 0x4101);
> > + phy_write(phy, 0x09, 0x0e00);
> > + phy_write(phy, 0x04, 0x01e1);
> > + phy_write(phy, 0x00, 0x9140);
> > + phy_write(phy, 0x00, 0x1140);
> > +
> > + return 0;
> > +}
> > +
> > +static struct mii_phy_ops m88e1111_phy_ops = {
> > + .init = m88e1111_init,
> > + .setup_aneg = genmii_setup_aneg,
> > + .setup_forced = genmii_setup_forced,
> > + .poll_link = genmii_poll_link,
> > + .read_link = genmii_read_link
> > +};
> > +
> > +static struct mii_phy_def m88e1111_phy_def = {
> > +
> > + .phy_id = 0x01410CC0,
> > + .phy_id_mask = 0x0ffffff0,
> > + .name = "Marvell 88E1111 Ethernet",
> > + .ops = &m88e1111_phy_ops,
> > +};
> > +
> > static struct mii_phy_def *mii_phy_table[] = {
> > &cis8201_phy_def,
> > + &bcm5248_phy_def,
> > + &m88e1111_phy_def,
> > &genmii_phy_def,
>
> Seems sane to me -- ACK -- but we have multiple people sending me
> patches for a single driver. That's normal for janitorial cleanups
> across the whole tree, but discouraged when multiple people are actively
> working on the same driver.
>
> Please coordinate, and have ONE person send me patches...
Who else is sending you patches? Valentine is the only one I've seen
send patches recently...
josh
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] ucc_geth: Fix build break introduced by commit 09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
From: Jeff Garzik @ 2007-10-15 18:51 UTC (permalink / raw)
To: Emil Medve; +Cc: netdev, akpm, leoli, linuxppc-dev
In-Reply-To: <1192455830-1028-1-git-send-email-Emilian.Medve@Freescale.com>
Emil Medve wrote:
> drivers/net/ucc_geth.c: In function 'ucc_geth_rx':
> drivers/net/ucc_geth.c:3483: error: 'dev' undeclared (first use in this function)
> drivers/net/ucc_geth.c:3483: error: (Each undeclared identifier is reported only once
> drivers/net/ucc_geth.c:3483: error: for each function it appears in.)
> make[2]: *** [drivers/net/ucc_geth.o] Error 1
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
>
> Here is a convenient link for the culprit patch: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=commit;h=09f75cd7bf13720738e6a196cc0107ce9a5bd5a0
>
> netdev-2.6> scripts/checkpatch.pl 0001-POWERPC-ucc_geth-Fix-build-break-introduced-by-co.patch
> Your patch has no obvious style problems and is ready for submission.
applied
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 18:53 UTC (permalink / raw)
To: Josh Boyer; +Cc: Valentine Barshak, Michael Ellerman, linuxppc-dev, netdev
In-Reply-To: <20071015134813.6aacdcca@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:27:23 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>
>> Valentine Barshak wrote:
>>> This patch adds BCM5248 and Marvell 88E1111 PHY support to NEW EMAC driver.
>>> These PHY chips are used on PowerPC 440EPx boards.
>>> The PHY code is based on the previous work by Stefan Roese <sr@denx.de>
>>>
>>> Signed-off-by: Stefan Roese <sr@denx.de>
>>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>>> ---
>>> drivers/net/ibm_newemac/phy.c | 39 +++++++++++++++++++++++++++++++++++++++
>>> 1 files changed, 39 insertions(+)
>>>
>>> --- linux.orig/drivers/net/ibm_newemac/phy.c 2007-06-15 21:45:18.000000000 +0400
>>> +++ linux/drivers/net/ibm_newemac/phy.c 2007-06-15 20:45:15.000000000 +0400
>>> @@ -306,8 +306,47 @@
>>> .ops = &cis8201_phy_ops
>>> };
>>>
>>> +static struct mii_phy_def bcm5248_phy_def = {
>>> +
>>> + .phy_id = 0x0143bc00,
>>> + .phy_id_mask = 0x0ffffff0,
>>> + .name = "BCM5248 10/100 SMII Ethernet",
>>> + .ops = &generic_phy_ops
>>> +};
>>> +
>>> +static int m88e1111_init(struct mii_phy *phy)
>>> +{
>>> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>>> + phy_write(phy, 0x14, 0x0ce3);
>>> + phy_write(phy, 0x18, 0x4101);
>>> + phy_write(phy, 0x09, 0x0e00);
>>> + phy_write(phy, 0x04, 0x01e1);
>>> + phy_write(phy, 0x00, 0x9140);
>>> + phy_write(phy, 0x00, 0x1140);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static struct mii_phy_ops m88e1111_phy_ops = {
>>> + .init = m88e1111_init,
>>> + .setup_aneg = genmii_setup_aneg,
>>> + .setup_forced = genmii_setup_forced,
>>> + .poll_link = genmii_poll_link,
>>> + .read_link = genmii_read_link
>>> +};
>>> +
>>> +static struct mii_phy_def m88e1111_phy_def = {
>>> +
>>> + .phy_id = 0x01410CC0,
>>> + .phy_id_mask = 0x0ffffff0,
>>> + .name = "Marvell 88E1111 Ethernet",
>>> + .ops = &m88e1111_phy_ops,
>>> +};
>>> +
>>> static struct mii_phy_def *mii_phy_table[] = {
>>> &cis8201_phy_def,
>>> + &bcm5248_phy_def,
>>> + &m88e1111_phy_def,
>>> &genmii_phy_def,
>> Seems sane to me -- ACK -- but we have multiple people sending me
>> patches for a single driver. That's normal for janitorial cleanups
>> across the whole tree, but discouraged when multiple people are actively
>> working on the same driver.
>>
>> Please coordinate, and have ONE person send me patches...
>
> Who else is sending you patches? Valentine is the only one I've seen
> send patches recently...
It's a zoo :)
Al Viro (3):
typo in ibm_newemac/rgmii.c
skb->tail in ibm_newemac should be skb_tail_pointer()
ibm_newemac annotations (iomem, NULL noise)
David Gibson (1):
Device tree aware EMAC driver
Michael Ellerman (3):
Update ibm_newemac to use dcr_host_t.base
Add dcr_host_t.base in dcr_read()/dcr_write()
Use dcr_host_t.base in dcr_unmap()
Roland Dreier (2):
ibm_new_emac: Nuke SET_MODULE_OWNER() use
ibm_emac: Convert to use napi_struct independent of struct net_device
vbarshak@ru.mvista.com (1):
Fix typo in new EMAC driver.
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Josh Boyer @ 2007-10-15 18:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Valentine Barshak, Michael Ellerman, linuxppc-dev, netdev
In-Reply-To: <4713B726.6080404@garzik.org>
On Mon, 15 Oct 2007 14:53:26 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> >> Seems sane to me -- ACK -- but we have multiple people sending me
> >> patches for a single driver. That's normal for janitorial cleanups
> >> across the whole tree, but discouraged when multiple people are actively
> >> working on the same driver.
> >>
> >> Please coordinate, and have ONE person send me patches...
> >
> > Who else is sending you patches? Valentine is the only one I've seen
> > send patches recently...
>
> It's a zoo :)
Wow, indeed.
> Al Viro (3):
> typo in ibm_newemac/rgmii.c
Val sent this as well. Either one works.
> skb->tail in ibm_newemac should be skb_tail_pointer()
> ibm_newemac annotations (iomem, NULL noise)
Ack on those.
> David Gibson (1):
> Device tree aware EMAC driver
That's the initial commit :)
> Michael Ellerman (3):
> Update ibm_newemac to use dcr_host_t.base
> Add dcr_host_t.base in dcr_read()/dcr_write()
> Use dcr_host_t.base in dcr_unmap()
Missed those, but I see you applied them which is good.
> Roland Dreier (2):
> ibm_new_emac: Nuke SET_MODULE_OWNER() use
> ibm_emac: Convert to use napi_struct independent of struct net_device
I never saw either of these. I'm also beginning to wonder if one of
them broke things because I can't currently get ibm_newemac to work.
> vbarshak@ru.mvista.com (1):
> Fix typo in new EMAC driver.
Same fix as Al's.
Anyway, we can queue patches to this through me if you'd like.
josh
^ permalink raw reply
* Re: [PATCH] PowerPC: Add BCM5248 and Marvell 88E1111 PHY support to NEW EMAC.
From: Jeff Garzik @ 2007-10-15 19:04 UTC (permalink / raw)
To: Josh Boyer; +Cc: netdev, linuxppc-dev
In-Reply-To: <20071015135959.5b603d7d@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 15 Oct 2007 14:53:26 -0400
> Jeff Garzik <jeff@garzik.org> wrote:
>>>> Seems sane to me -- ACK -- but we have multiple people sending me
>>>> patches for a single driver. That's normal for janitorial cleanups
>>>> across the whole tree, but discouraged when multiple people are actively
>>>> working on the same driver.
>>>>
>>>> Please coordinate, and have ONE person send me patches...
>>> Who else is sending you patches? Valentine is the only one I've seen
>>> send patches recently...
>> It's a zoo :)
>
> Wow, indeed.
>
>> Al Viro (3):
>> typo in ibm_newemac/rgmii.c
>
> Val sent this as well. Either one works.
>
>> skb->tail in ibm_newemac should be skb_tail_pointer()
>> ibm_newemac annotations (iomem, NULL noise)
>
> Ack on those.
>
>> David Gibson (1):
>> Device tree aware EMAC driver
>
> That's the initial commit :)
>
>> Michael Ellerman (3):
>> Update ibm_newemac to use dcr_host_t.base
>> Add dcr_host_t.base in dcr_read()/dcr_write()
>> Use dcr_host_t.base in dcr_unmap()
>
> Missed those, but I see you applied them which is good.
>
>> Roland Dreier (2):
>> ibm_new_emac: Nuke SET_MODULE_OWNER() use
>> ibm_emac: Convert to use napi_struct independent of struct net_device
>
> I never saw either of these. I'm also beginning to wonder if one of
> them broke things because I can't currently get ibm_newemac to work.
>
>> vbarshak@ru.mvista.com (1):
>> Fix typo in new EMAC driver.
>
> Same fix as Al's.
All those are what's upstream, except for the Michael Ellerman patches.
FWIW it was generated using
git log drivers/net/ibm_newemac | git shortlog
> Anyway, we can queue patches to this through me if you'd like.
I would ideally like a single active patch generator (even if they are
merely reviewed others work sometimes).
Outside of that, I'm hoping you and the other people listed making
changes will self-organize without my help :)
Jeff
^ permalink raw reply
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Jeff Garzik @ 2007-10-15 19:06 UTC (permalink / raw)
To: Domen Puncer; +Cc: galak, linuxppc-dev, grant.likely, tnt, netdev
In-Reply-To: <20071014075511.GC3000@nd47.coderock.org>
Domen Puncer wrote:
> Hello!
>
> If there are no objections, I would like to get this merged
> when bestcomm goes in (any time now?).
>
> It's split into four parts:
> 1 - device tree
> 2 - small bestcomm change
> 3 - the actual driver
> 4 - phy part of the driver
patches #3 and #4 need to be combined together.
Are the arch people OK with patches #1 and #2?
Jeff
^ permalink raw reply
* Re: [PATCH 1/6] Convert bonding timers to workqueues
From: Jay Vosburgh @ 2007-10-15 19:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, andy
In-Reply-To: <4713B44E.7030902@pobox.com>
Jeff Garzik <jgarzik@pobox.com> wrote:
>Jay Vosburgh wrote:
>> Convert bonding timers to workqueues. This converts the various
>> monitor functions to run in periodic work queues instead of timers. This
>> patch introduces the framework and convers the calls, but does not resolve
>> various locking issues, and does not stand alone.
>>
>> Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>
>"does not stand alone" == it is not bisectable? That's a problem.
The patch will compile fine (this is true for any point in the
series), but it's possible for bonding to deadlock or misbehave when
doing certain operations. Those problems are addressed in the later
patches.
I didn't want to just vomit out one big mega-patch that has the
whole set of changes, because that's harder to understand, and the later
patches generally address discrete issues.
Does that make you more or less nervous about its bisectability?
I can repost the whole thing as a big blob if that's what you'd prefer.
>Anyway, we have more fun fish to fry: after applying the IPoIB bonding
>patchset, this no longer applies...
Yah, I'll rebase it (once I know your blob vs. not-blob
preference). I wasn't sure how long the IPoIB mystery bug hunt was
going to take.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Grant Likely @ 2007-10-15 19:19 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Domen Puncer, galak, linuxppc-dev, tnt, netdev
In-Reply-To: <4713BA1C.2050604@pobox.com>
On 10/15/07, Jeff Garzik <jgarzik@pobox.com> wrote:
> Domen Puncer wrote:
> > Hello!
> >
> > If there are no objections, I would like to get this merged
> > when bestcomm goes in (any time now?).
> >
> > It's split into four parts:
> > 1 - device tree
> > 2 - small bestcomm change
> > 3 - the actual driver
> > 4 - phy part of the driver
>
> patches #3 and #4 need to be combined together.
>
> Are the arch people OK with patches #1 and #2?
Yes, I'll be pushing both to Paulus shortly.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] forcedeth: Fix MAC address detection on network card (regression in 2.6.23)
From: Ayaz Abdulla @ 2007-10-14 21:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Michael Pyne, Andrew Morton, netdev
In-Reply-To: <4713B271.9010607@pobox.com>
Jeff Garzik wrote:
> Michael Pyne wrote:
>
>> Partially revert a change to mac address detection introduced to the
>> forcedeth driver. The change was intended to correct mac address
>> detection for newer nVidia chipsets where the mac address was stored
>> in reverse order. One of those chipsets appears to still have the mac
>> address in reverse order (or at least, it does on my system).
>>
>> Signed-off-by: Michael J. Pyne <michael.pyne@kdemail.net>
>> ---
>> The change that broke mac address detection for my card was commit
>> ef756b3e56c68a4d76d9d7b9a73fa8f4f739180f "forcedeth: mac address correct"
>>
>> My network card is an nVidia built-in Ethernet card, output from lspci
>> as follows (with text and numeric ids):
>> $ lspci | grep Ethernet
>> 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
>> $ lspci -n | grep 07.0
>> 00:07.0 0680: 10de:03ef (rev a2)
>>
>> The vendor id is, of course, nVidia. The device id corresponds to the
>> NVIDIA_NVENET_19 entry.
>>
>> The included patch fixes the MAC address detection on my system.
>> Interestingly, the MAC address appears to be in the range reserved for
>> my motherboard manufacturer (Gigabyte) and not nVidia.
>>
>> If you need any further information about my hardware configuration
>> just let me know.
>>
>> Regards,
>> - Michael Pyne
>>
>> --- a/drivers/net/forcedeth.c 2007-10-11 22:01:26 -0400
>> +++ b/drivers/net/forcedeth-new.c 2007-10-11 22:06:52 -0400
>> @@ -5513,7 +5513,7 @@ static struct pci_device_id pci_tbl[] = },
>> { /* MCP61 Ethernet Controller */
>> PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
>> PCI_DEVICE_ID_NVIDIA_NVENET_19),
>> - .driver_data =
>> DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|
>> DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|
>>
>> DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT|DEV_HAS_CORRECT_MACADDR,
>> + .driver_data =
>> DEV_NEED_TIMERIRQ|DEV_NEED_LINKTIMER|DEV_HAS_HIGH_DMA|
>> DEV_HAS_POWER_CNTRL|DEV_HAS_MSI|DEV_HAS_PAUSEFRAME_TX|DEV_HAS_STATISTICS_V2|
>>
>> DEV_HAS_TEST_EXTENDED|DEV_HAS_MGMT_UNIT,
>> },
>> { /* MCP65 Ethernet Controller */
>> PCI_DEVICE(PCI_VENDOR_ID_NVIDIA,
>> PCI_DEVICE_ID_NVIDIA_NVENET_20),
>
>
> your patch is word-wrapped. Anyway...
>
> Ayaz -- ACK this patch?
ASUS should be contacted to fix their SBIOS instead of patching the driver.
MCP61 reference has the correct address programmed by SBIOS. There are
other vendor boards that will have correct address (as defined by MCP61
reference).
>
>
>
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH][BNX2X] round three
From: David Miller @ 2007-10-15 19:38 UTC (permalink / raw)
To: eliezert; +Cc: andi, netdev, jeff, mchan
In-Reply-To: <1192462049.29746.158.camel@eliezer>
From: "Eliezer Tamir" <eliezert@broadcom.com>
Date: Mon, 15 Oct 2007 17:27:29 +0200
> Unfortunately, the firmware code is different for LE and BE machines.
> We had issues with the BE firmware that appear to be resolved.
> Hopefully, the next version will have both.
If this means we get two copies of the firmware, this should be
rethought. The space cost of the firmware (both in terms of source
code size and object code size) is already enormous.
I would definitely prefer if there were only little-endian firmware,
and the driver uses "cpu_to_le32()" and friends to access chip shared
data structures.
Most cpus have endian swapping loads and stores, accessible via
cpu_to_le32p() and similar interfaces, so the cost on big-endian of
doing things this way is very close to zero.
^ permalink raw reply
* Re: [PATCH][BNX2X] round three
From: David Miller @ 2007-10-15 19:42 UTC (permalink / raw)
To: eliezert; +Cc: andi, netdev, jeff, mchan
In-Reply-To: <1192465323.29746.170.camel@eliezer>
From: "Eliezer Tamir" <eliezert@broadcom.com>
Date: Mon, 15 Oct 2007 18:22:03 +0200
> On Mon, 2007-10-15 at 18:05 +0200, Andi Kleen wrote:
> > > This is not a driver issue.
> > > Unfortunately, the firmware code is different for LE and BE machines.
> > > We had issues with the BE firmware that appear to be resolved.
> > > Hopefully, the next version will have both.
> >
> > If the firmware is big it might be better to just add the necessary
> > conversions to the driver and always use BE. Endian conversions
> > tend to be very cheap.
>
> For a given architecture, only the right version of the microcode is
> compiled, so the binary only contains one copy of the microcode.
But it still takes up source tree space.
> The good news is that future versions of the device will not have this
> issue.
>
The better news is that you only need the little-endian firmware
even with these chips, simple assume little-endian for all
chip shared data-structures and swap in the driver as we've
explained to you.
The cost for big-endian cpus is almost nothing.
^ permalink raw reply
* Re: [PATCH] isdn compile fix (resend)
From: David Miller @ 2007-10-15 19:52 UTC (permalink / raw)
To: kkeil; +Cc: den, netdev
In-Reply-To: <20071015160202.GA25812@pingi.kke.suse.de>
From: Karsten Keil <kkeil@suse.de>
Date: Mon, 15 Oct 2007 18:02:02 +0200
> On Mon, Oct 15, 2007 at 06:44:56PM +0400, Denis V. Lunev wrote:
> Compilation fix. The problem appears after
> 7c076d1de869256848dacb8de0050a3a390f95df by Karsten Keil <kkeil@suse.de>
>
> Acked-by: Karsten Keil <kkeil@suse.de>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] kmalloc+memset -> kzalloc in frag_alloc_queue
From: David Miller @ 2007-10-15 19:53 UTC (permalink / raw)
To: den; +Cc: netdev
In-Reply-To: <20071015144841.GA1009@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Mon, 15 Oct 2007 18:48:41 +0400
> kmalloc + memset -> kzalloc in frag_alloc_queue
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] Ensure that pneigh_lookup is protected with RTNL
From: David Miller @ 2007-10-15 19:54 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47136D71.4000108@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Mon, 15 Oct 2007 17:38:57 +0400
> The pnigh_lookup is used to lookup proxy entries and to
> create them in case lookup failed.
>
> However, the "creation" code does not perform the re-lookup
> after GFP_KERNEL allocation. This is done because the code
> is expected to be protected with the RTNL lock, so add the
> assertion (mainly to address future questions from new network
> developers like me :) ).
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Thanks for this patch, applied.
^ permalink raw reply
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