[gPXE] Trying to extend TG3 driver

[Thomas Miletich]

Hi
If you really need the structures I think it's appropriate to add them
to a generic header file, like mii.h and phy.h.
Preferably both changes as 2 different git commits, and the driver
itself is again another commit.

Anyway, often it turns out that you don't even need the whole
structure. Often the driver uses only a few, sometimes even only a
single element of those structures which can easily go to the NIC's
private structure(struct tg3). This saves code size and makes things
easier to understand.

The mii structures are also often used for ethtool support, and after
ethtool support is removed there is no need to keep them around any
longer.

Summary: If only a few variables in the mii and phy structures are
used, put them in 'struct tg3' and store them there. If many variables
are used, put the structures to mii.h and to phy.h(not sure if it
already exists).

Thanks
Thomas

On Mon, Nov 23, 2009 at 6:59 PM, Nick Couchman <Nick.Couchman at seakr.com> wrote:
> Okay, so a follow-up question or two...
>
> In working on this driver, I've run into some issues where some of the definitions in the tg3 struct aren't defined outside of the Linux kernel code.  One such issue is the mii_bus structure, which creates the mdio_bus variable in the tg3 struct.  This structure is used heavily in the link and phy setup, negotiation, and reset code.  I noticed in a couple of headers that there is a note about bringing over more of the Linux kernel mii.h stuff into the gPXE mii.h file, so I'm wondering whether that should be done, now, too, or whether the code in tg3 should be written around it so that those things aren't required.  As a specific example, the tg3_adjust_link function, there is the following code:
>
>        u8 oldflowctrl, linkmesg = 0;
>        u32 mac_mode, lcl_adv, rmt_adv;
>        struct tg3 *tp = netdev_priv(dev);
>        struct phy_device *phydev = tp->mdio_bus.phy_map[PHY_ADDR];
>
> The phydev variable is assigned it's value from mdio_bus.phy_map, and mdio_bus is an mii_bus structure.  Is there another way that phydev should be grabbed, or does it really need to be via mii_bus/mdio_bus?
>
> I'm also looking at the r8169 files as an example, but there are several (seemingly) significant differences in how those drivers are implemented, which means I can't really map over everything 1-to-1 to get a great idea of how the tg3 should look when it's done.  Maybe the differences aren't as extensive as they appear, but the tg3 code is pretty complex as compared to the r8169 driver in gPXE.
>
> Thanks,
> Nick
>
>
>>>> On 2009/11/20 at 17:12, Thomas Miletich <thomas.miletich at gmail.com> wrote:
>> There is some network driver API documentation at
>> http://etherboot.org/wiki/soc/2008/mdeck/notes/gpxe_driver_api and
>> http://etherboot.org/wiki/dev/netdriverapi
>> If you look at the current driver you will notice that is still using
>> the deprecated etherboot API. Yet another reason for a rewrite :)
>> Unfortunately we don't have much more documentation about drivers, but
>> the r8169.c driver in gPXE in my opinion is a good example driver.
>> Chapter 17 of the book 'Linux Device Drivers' is very useful too:
>> http://lwn.net/Kernel/LDD3/
>> the gPXE network driver and PCI API is basically a simplified version
>> of the linux API, so many things still apply. It will also help to
>> understand the linux tg3 driver better.
>>
>> Thanks and good luck
>> Thomas
>>
>> On Sat, Nov 21, 2009 at 12:55 AM, Nick Couchman <Nick.Couchman at seakr.com>
>> wrote:
>>>>>> On 2009/11/20 at 16:45, Thomas Miletich <thomas.miletich at gmail.com> wrote:
>>>> Hello Nick
>>>> as you have noticed the current tg3 driver in gPXE is very
>>>> out-of-date. The driver in linux mainline supports around twice as
>>>> many cards as the gPXE driver. You will probably have to backport many
>>>> special cases and PHY support functions.
>>>
>>> Yeah, I noticed that - doesn't look like tg3 has gotten a lot of attention in
>> the gPXE development process.  Maybe I can help that :-).
>>>
>>>>
>>>> Depending on how much time you are willing to invest, I think a
>>>> complete re-port of the current linux driver and completely dropping
>>>> the current gPXE one is worth considering. There are also some bugs
>>>> with cards that are actually supposed to work. It's not unlikely that
>>>> you run into some of them too.
>>>
>>> I wondered if this might be the answer...so maybe I'll give it a shot.  Any
>> idea off the top of your head what the main differences are between the Linux
>> kernel drivers and the gPXE drivers?  Obviously things like module code and
>> such, but any other hints would be appreciated.
>>>
>>>>
>>>> undionly.kpxe should work, if it is loaded by the tg3's PXE rom.
>>>
>>> Will give it a shot.  I'd really like to flash the Broadcom PXE code with
>> gPXE on these Optiplex units, so building in support I think is the only
>> thing that will really work in the long run.
>>>
>>>>
>>>> Driver questions are often better answered interactively, please feel
>>>> free to join #etherboot on irc.freenode.net. There are some people
>>>> than can help with drivers.
>>>
>>> I'll keep this in mind - unfortunately the time I can spend on things like
>> this is often sporadic, and I can't always sit down and work for hours at a
>> time, so interactive help often doesn't work real well for me.
>>>
>>> Thanks - Nick
>>>
>>>
>>>
>>> --------
>>> This e-mail may contain confidential and privileged material for the sole use
>> of the intended recipient.  If this email is not intended for you, or you are
>> not responsible for the delivery of this message to the intended recipient,
>> please note that this message may contain SEAKR Engineering (SEAKR)
>> Privileged/Proprietary Information.  In such a case, you are strictly
>> prohibited from downloading, photocopying, distributing or otherwise using
>> this message, its contents or attachments in any way.  If you have received
>> this message in error, please notify us immediately by replying to this e-mail
>> and delete the message from your mailbox.  Information contained in this
>> message that does not relate to the business of SEAKR is neither endorsed by
>> nor attributable to SEAKR.
>>>
>
>
>
> --------
> This e-mail may contain confidential and privileged material for the sole use of the intended recipient.  If this email is not intended for you, or you are not responsible for the delivery of this message to the intended recipient, please note that this message may contain SEAKR Engineering (SEAKR) Privileged/Proprietary Information.  In such a case, you are strictly prohibited from downloading, photocopying, distributing or otherwise using this message, its contents or attachments in any way.  If you have received this message in error, please notify us immediately by replying to this e-mail and delete the message from your mailbox.  Information contained in this message that does not relate to the business of SEAKR is neither endorsed by nor attributable to SEAKR.
>