[ECOS] ethernet driver package idea

[ECOS] ethernet driver package idea

[Trenton D. Adams]

I was thinking, we could replace "eth0" with __DEVICE_NAME like below.
ETH_DRV_SC(edb7xxx_sc,
           &_cs8900_priv_data, // Driver specific data
           __DEVICE_NAME,             // Name for this interface
           cs8900_start,
           cs8900_stop,
           cs8900_control,
           cs8900_can_send,
           cs8900_send,
           cs8900_recv,
           cs8900_deliver,     // "pseudoDSR" called from fast net
thread
           cs8900_int,         // poll function, encapsulates ISR and
DSR
           cs8900_int_vector);

Then we add the following to
"devs\eth\arm\edb7xxx\current\cdl\edb7xxx_eth_drivers.cdl"

    cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP_OPTIONS {
        display "Device Options for CS8900"
#        active_if (CYGHWR_NET_DRIVER_ETH1 == 1)
        flavor none
        no_define

        cdl_interface CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP {
            display "Device Options for CS8900"
#            requires 1 == CYGHWR_NET_DRIVER_ETH1_SETUP
            no_define
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 {
            display "Use 'eth0'"
            default_value 1
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH0
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth0\""
            }
            description "Select this option to use the ethernet driver
as eth0"
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 {
            display "Use 'eth1'"
            default_value 0
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH1
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth1\""
            }
            description "Select this option to use the ethernet driver
as eth1"
        }
    }

I can't get the options to switch from check boxes to radio buttons
though.  How do I do that?


This should probably be done on all ethernet hardware drivers as a
standard no?

p.s.
It works fine for me.  I switched it to eth1, and my program still
worked just fine.  Just those damn checkboxes! :)

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

RE: [ECOS] ethernet driver package idea

[Trenton D. Adams]

I just realized something too.  What if another ethernet hardware driver
uses eth0?

Would a "requires (CYGHWR_NET_DRIVER_ETH0 == 0)" be sufficient, or would
that conflict with it's self since it "implements" that?

What about maybe an "active_if (CYGHWR_NET_DRIVER_ETH0 == 0)"

Also, should I use "no_define" on the
CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 and
CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 options?  It doesn't really
matter if they do get defined I suppose, but just to be clear that their
not actually used in code somewhere right?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Trenton D.
Adams
Sent: Thursday, August 23, 2001 12:41 PM
To: 'eCos Discussion'
Subject: [ECOS] ethernet driver package idea


I was thinking, we could replace "eth0" with __DEVICE_NAME like below.
ETH_DRV_SC(edb7xxx_sc,
           &_cs8900_priv_data, // Driver specific data
           __DEVICE_NAME,             // Name for this interface
           cs8900_start,
           cs8900_stop,
           cs8900_control,
           cs8900_can_send,
           cs8900_send,
           cs8900_recv,
           cs8900_deliver,     // "pseudoDSR" called from fast net
thread
           cs8900_int,         // poll function, encapsulates ISR and
DSR
           cs8900_int_vector);

Then we add the following to
"devs\eth\arm\edb7xxx\current\cdl\edb7xxx_eth_drivers.cdl"

    cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP_OPTIONS {
        display "Device Options for CS8900"
#        active_if (CYGHWR_NET_DRIVER_ETH1 == 1)
        flavor none
        no_define

        cdl_interface CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP {
            display "Device Options for CS8900"
#            requires 1 == CYGHWR_NET_DRIVER_ETH1_SETUP
            no_define
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 {
            display "Use 'eth0'"
            default_value 1
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH0
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth0\""
            }
            description "Select this option to use the ethernet driver
as eth0"
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 {
            display "Use 'eth1'"
            default_value 0
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH1
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth1\""
            }
            description "Select this option to use the ethernet driver
as eth1"
        }
    }

I can't get the options to switch from check boxes to radio buttons
though.  How do I do that?


This should probably be done on all ethernet hardware drivers as a
standard no?

p.s.
It works fine for me.  I switched it to eth1, and my program still
worked just fine.  Just those damn checkboxes! :)

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

RE: [ECOS] CS8900 ethernet driver PATCH

[Trenton D. Adams]

I changed the subject because it was a little off of what it should be!
:)  It used to be called "ethernet driver package idea".

Anyhow, I came up with the following.  I think this will work for using
two ethernet devices.  Note the 
            requires (CYGHWR_NET_DRIVER_ETH_0 == 0)
            implements CYGHWR_NET_DRIVER_ETH_0
and the 
            requires (CYGHWR_NET_DRIVER_ETH_1 == 0)
            implements CYGHWR_NET_DRIVER_ETH_1

My "active_if" and "requires" statements from before did not work.
active_if caused the config tool to lock up.  Requires just caused a
conflict that couldn't be resolved unless you disable it.

I don't actually have two ethernet device drivers that work with the
EDB7XXX that I can test it with, do I?

All previous messages about this topic are below.


    cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP_OPTIONS {
        display "Device Options for CS8900"
        flavor none
        no_define

        cdl_interface CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP {
            display "Device Options for CS8900"
            no_define
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 {
            display "Use 'eth0'"
            default_value 1
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH0
            requires (CYGHWR_NET_DRIVER_ETH_0 == 0)
            implements CYGHWR_NET_DRIVER_ETH_0
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth0\""
            }
            no_define
            description "Select this option to use the ethernet driver
as eth0"
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 {
            display "Use 'eth1'"
            default_value 0
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH1
            requires (CYGHWR_NET_DRIVER_ETH_1 == 0)
            implements CYGHWR_NET_DRIVER_ETH_1
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth1\""
            }
            no_define
            description "Select this option to use the ethernet driver
as eth1"
        }
    }


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Trenton D.
Adams
Sent: Thursday, August 23, 2001 1:24 PM
To: 'eCos Discussion'
Subject: RE: [ECOS] ethernet driver package idea


I just realized something too.  What if another ethernet hardware driver
uses eth0?

Would a "requires (CYGHWR_NET_DRIVER_ETH0 == 0)" be sufficient, or would
that conflict with it's self since it "implements" that?

What about maybe an "active_if (CYGHWR_NET_DRIVER_ETH0 == 0)"

Also, should I use "no_define" on the
CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 and
CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 options?  It doesn't really
matter if they do get defined I suppose, but just to be clear that their
not actually used in code somewhere right?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Trenton D.
Adams
Sent: Thursday, August 23, 2001 12:41 PM
To: 'eCos Discussion'
Subject: [ECOS] ethernet driver package idea


I was thinking, we could replace "eth0" with __DEVICE_NAME like below.
ETH_DRV_SC(edb7xxx_sc,
           &_cs8900_priv_data, // Driver specific data
           __DEVICE_NAME,             // Name for this interface
           cs8900_start,
           cs8900_stop,
           cs8900_control,
           cs8900_can_send,
           cs8900_send,
           cs8900_recv,
           cs8900_deliver,     // "pseudoDSR" called from fast net
thread
           cs8900_int,         // poll function, encapsulates ISR and
DSR
           cs8900_int_vector);

Then we add the following to
"devs\eth\arm\edb7xxx\current\cdl\edb7xxx_eth_drivers.cdl"

    cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP_OPTIONS {
        display "Device Options for CS8900"
#        active_if (CYGHWR_NET_DRIVER_ETH1 == 1)
        flavor none
        no_define

        cdl_interface CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP {
            display "Device Options for CS8900"
#            requires 1 == CYGHWR_NET_DRIVER_ETH1_SETUP
            no_define
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 {
            display "Use 'eth0'"
            default_value 1
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH0
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth0\""
            }
            description "Select this option to use the ethernet driver
as eth0"
        }

        cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 {
            display "Use 'eth1'"
            default_value 0
            implements CYGPKG_DEVS_ETH_ARM_EDB7XXX_SETUP
            implements CYGHWR_NET_DRIVER_ETH1
            define_proc {
                puts $cdl_header "#define __DEVICE_NAME \"eth1\""
            }
            description "Select this option to use the ethernet driver
as eth1"
        }
    }

I can't get the options to switch from check boxes to radio buttons
though.  How do I do that?


This should probably be done on all ethernet hardware drivers as a
standard no?

p.s.
It works fine for me.  I switched it to eth1, and my program still
worked just fine.  Just those damn checkboxes! :)

Trenton D. Adams
Extreme Engineering
#17, 6025 - 12 St. SE
Calgary, Alberta, Canada
T2H 2K1

Phone: 403 640 9494 ext-208
Fax: 403 640 9599

http://www.extremeeng.com

Re: [ECOS] ethernet driver package idea

[Bart Veer]

>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> I just realized something too. What if another ethernet
    Trenton> hardware driver uses eth0?

    Trenton> Would a "requires (CYGHWR_NET_DRIVER_ETH0 == 0)" be
    Trenton> sufficient, or would that conflict with it's self since
    Trenton> it "implements" that?

    Trenton> What about maybe an "active_if (CYGHWR_NET_DRIVER_ETH0 == 0)"

    Trenton> Also, should I use "no_define" on the
    Trenton> CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 and
    Trenton> CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 options? It
    Trenton> doesn't really matter if they do get defined I suppose,
    Trenton> but just to be clear that their not actually used in code
    Trenton> somewhere right?

This issue has already been addressed in the current sources, using
CDL interfaces. Take a look at the USB-ethernet package in
packages/io/usb/eth/slave/current/cdl/usbs_eth.cdl. This package will
provide an eth0 device if there is not already one present in the
system, or an eth1 device if some other package implements eth0 i.e.
if there is a real ethernet device in addition to the one emulated
over USB.

    2001-07-10  Bart Veer  <bartv@redhat.com>

	* doc/usbseth.sgml, doc/*.html:
	Document the below changes.

	* cdl/usbs_eth.cdl:
	The USB-ethernet device now registers itself as either eth0 or
	eth1 by default, depending on what else is present in the system.

Note that for these changes to be fully effective you also need up to
date host-side tools, specifically the following change to libcdl:

    2001-07-10  Bart Veer  <bartv@redhat.com>

	* transact.cxx (is_preferable_to): 
	Fine-tune the determination of which of two transactions has less
	impact on the system.
	
	* infer.cxx (infer_handle_interface_value):
	Add inference engine support for constraints of the form
	(xxx == 0) and (xxx = 1), where xxx is an interface.

Prior to these libcdl enhancements the configuration system would
report a conflict if there were two eth0 devices, but would not be
able to resolve the conflict automatically.

Bart

RE: [ECOS] ethernet driver package idea

[Trenton D. Adams]

But this is only done on the USB interface then?  Doing it the way I did
it wouldn't require an update of the config tool though!  Also, do you
have the new tool ready for download?  I personally don't have the time
at the moment to install wxWindows, and then recompile the tool.  If
anything goes wrong, it's wasted my employer's money, and I don't want
to do that.

Besides, yours seems to work with the Windows GUI config tool 2.04.  I
can't be sure because I don't have two ethernet interfaces to check it
with.  Is the conflict resolution thing the only problem with it?

So, you want me to create a similar one for the edb7xxx cs8900 driver
then?

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Bart Veer
Sent: Friday, August 24, 2001 5:22 AM
To: tadams@theone.dnsalias.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] ethernet driver package idea


>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> I just realized something too. What if another ethernet
    Trenton> hardware driver uses eth0?

    Trenton> Would a "requires (CYGHWR_NET_DRIVER_ETH0 == 0)" be
    Trenton> sufficient, or would that conflict with it's self since
    Trenton> it "implements" that?

    Trenton> What about maybe an "active_if (CYGHWR_NET_DRIVER_ETH0 ==
0)"

    Trenton> Also, should I use "no_define" on the
    Trenton> CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 and
    Trenton> CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 options? It
    Trenton> doesn't really matter if they do get defined I suppose,
    Trenton> but just to be clear that their not actually used in code
    Trenton> somewhere right?

This issue has already been addressed in the current sources, using
CDL interfaces. Take a look at the USB-ethernet package in
packages/io/usb/eth/slave/current/cdl/usbs_eth.cdl. This package will
provide an eth0 device if there is not already one present in the
system, or an eth1 device if some other package implements eth0 i.e.
if there is a real ethernet device in addition to the one emulated
over USB.

    2001-07-10  Bart Veer  <bartv@redhat.com>

	* doc/usbseth.sgml, doc/*.html:
	Document the below changes.

	* cdl/usbs_eth.cdl:
	The USB-ethernet device now registers itself as either eth0 or
	eth1 by default, depending on what else is present in the
system.

Note that for these changes to be fully effective you also need up to
date host-side tools, specifically the following change to libcdl:

    2001-07-10  Bart Veer  <bartv@redhat.com>

	* transact.cxx (is_preferable_to): 
	Fine-tune the determination of which of two transactions has
less
	impact on the system.
	
	* infer.cxx (infer_handle_interface_value):
	Add inference engine support for constraints of the form
	(xxx == 0) and (xxx = 1), where xxx is an interface.

Prior to these libcdl enhancements the configuration system would
report a conflict if there were two eth0 devices, but would not be
able to resolve the conflict automatically.

Bart

Re: [ECOS] ethernet driver package idea

[Bart Veer]

>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> But this is only done on the USB interface then?

When an ethernet driver is likely to be the only one present on a
given target then it can just default to eth0 - in most circumstances
that will work just fine. For example, if the processor has a single
on-chip ethernet device then usually that will be the only ethernet
device in the target system.

The USB ethernet device is different, in that it has no way of
guessing whether or not another ethernet device is present. Hence it
has more complicated CDL which makes sure that the right thing
happens: if it provides the only ethernet interface in the system then
it will use eth0; if there is a real ethernet device then that can
stay as eth0 and the USB-ethernet will become eth1.

For something like a driver for a PCMCIA plugin card, much the same
applies. That driver has no way of knowing whether or not another
ethernet device is present on the target hardware, so it should adapt. 

    Trenton> Doing it the way I did it wouldn't require an update of
    Trenton> the config tool though! Also, do you have the new tool
    Trenton> ready for download? I personally don't have the time at
    Trenton> the moment to install wxWindows, and then recompile the
    Trenton> tool. If anything goes wrong, it's wasted my employer's
    Trenton> money, and I don't want to do that.

    Trenton> Besides, yours seems to work with the Windows GUI config
    Trenton> tool 2.04. I can't be sure because I don't have two
    Trenton> ethernet interfaces to check it with. Is the conflict
    Trenton> resolution thing the only problem with it?

I do not know offhand whether 2.04 includes the required libcdl
changes, that is why I included the libcdl ChangeLog entry. If 2.04
was built before 2001-07-10 then it cannot have the required changes.
If it was built after 2001-07-10 then it almost certainly does have
the required changes. Take a look at Help->About to find out when the
configtool was built. The libcdl changes were specifically to cope
with targets that already have an ethernet interface and you are now
adding a second one such as USB-ethernet.

Bart

RE: [ECOS] ethernet driver package idea

[Trenton D. Adams]

[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]

We are going to have two interfaces on our board.  The cs8900 and the
Wavelan PC card.  So, this option is helpful because I can change them
to any device I want without going and editing the CDL and source.

The new CDL is attached if you want to incorporate it.

ETH_DRV_SC(edb7xxx_sc,
           &_cs8900_priv_data, // Driver specific data
           CYGDAT_ETHDRV_NAME,             // Name for this interface
           cs8900_start,
           cs8900_stop,
           cs8900_control,
           cs8900_can_send,
           cs8900_send,
           cs8900_recv,
           cs8900_deliver,     // "pseudoDSR" called from fast net
thread
           cs8900_int,         // poll function, encapsulates ISR and
DSR
           cs8900_int_vector);

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Bart Veer
Sent: Friday, August 24, 2001 9:42 AM
To: tadams@theone.dnsalias.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] ethernet driver package idea


>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> But this is only done on the USB interface then?

When an ethernet driver is likely to be the only one present on a
given target then it can just default to eth0 - in most circumstances
that will work just fine. For example, if the processor has a single
on-chip ethernet device then usually that will be the only ethernet
device in the target system.

The USB ethernet device is different, in that it has no way of
guessing whether or not another ethernet device is present. Hence it
has more complicated CDL which makes sure that the right thing
happens: if it provides the only ethernet interface in the system then
it will use eth0; if there is a real ethernet device then that can
stay as eth0 and the USB-ethernet will become eth1.

For something like a driver for a PCMCIA plugin card, much the same
applies. That driver has no way of knowing whether or not another
ethernet device is present on the target hardware, so it should adapt. 

    Trenton> Doing it the way I did it wouldn't require an update of
    Trenton> the config tool though! Also, do you have the new tool
    Trenton> ready for download? I personally don't have the time at
    Trenton> the moment to install wxWindows, and then recompile the
    Trenton> tool. If anything goes wrong, it's wasted my employer's
    Trenton> money, and I don't want to do that.

    Trenton> Besides, yours seems to work with the Windows GUI config
    Trenton> tool 2.04. I can't be sure because I don't have two
    Trenton> ethernet interfaces to check it with. Is the conflict
    Trenton> resolution thing the only problem with it?

I do not know offhand whether 2.04 includes the required libcdl
changes, that is why I included the libcdl ChangeLog entry. If 2.04
was built before 2001-07-10 then it cannot have the required changes.
If it was built after 2001-07-10 then it almost certainly does have
the required changes. Take a look at Help->About to find out when the
configtool was built. The libcdl changes were specifically to cope
with targets that already have an ethernet interface and you are now
adding a second one such as USB-ethernet.

Bart

[-- Attachment #2: edb7xxx_eth_drivers.cdl --]
[-- Type: text/plain, Size: 4965 bytes --]

# ====================================================================
#
#      edb7xxx_eth_drivers.cdl
#
#      Ethernet drivers - platform dependent support for Cirrus Logic
#                         EDB7xxx family of development boards
#
# ====================================================================
#####COPYRIGHTBEGIN####
#                                                                          
# -------------------------------------------                              
# The contents of this file are subject to the Red Hat eCos Public License 
# Version 1.1 (the "License"); you may not use this file except in         
# compliance with the License.  You may obtain a copy of the License at    
# http://www.redhat.com/                                                   
#                                                                          
# Software distributed under the License is distributed on an "AS IS"      
# basis, WITHOUT WARRANTY OF ANY KIND, either express or implied.  See the 
# License for the specific language governing rights and limitations under 
# the License.                                                             
#                                                                          
# The Original Code is eCos - Embedded Configurable Operating System,      
# released September 30, 1998.                                             
#                                                                          
# The Initial Developer of the Original Code is Red Hat.                   
# Portions created by Red Hat are                                          
# Copyright (C) 1998, 1999, 2000 Red Hat, Inc.                             
# All Rights Reserved.                                                     
# -------------------------------------------                              
#                                                                          
#####COPYRIGHTEND####
# ====================================================================
######DESCRIPTIONBEGIN####
#
# Author(s):      gthomas
# Original data:  gthomas
# Contributors:
# Date:           2000-01-25
#
#####DESCRIPTIONEND####
#
# ====================================================================

cdl_package CYGPKG_DEVS_ETH_ARM_EDB7XXX {
    display       "Cirrus Logic ethernet driver"

    parent        CYGPKG_IO_ETH_DRIVERS
    active_if	  CYGPKG_IO_ETH_DRIVERS
    active_if	  CYGPKG_HAL_ARM_EDB7XXX
    implements    CYGHWR_NET_DRIVERS

    include_dir   .
    include_files ; # none _exported_ whatsoever
    description   "Ethernet driver for Cirrus Logic EDB7xxx boards."
    compile       -library=libextras.a if_edb7xxx.c

    cdl_component CYGSEM_ARM_EDB7XXX_SET_ESA {
        display       "Set the ethernet station address"
        flavor        bool
        default_value 0
        description   "Enabling this option will allow the ethernet
          station address to be forced to the value set by the
          configuration.  This may be required if the hardware does
          not include a serial EEPROM for the ESA."

        cdl_option CYGDAT_ARM_EDB7XXX_ESA {
          display       "The ethernet station address"
          flavor        data
          default_value {"{0x08, 0x88, 0x12, 0x34, 0x56, 0x78}"}
          description   "The ethernet station address"
        }
    }


	cdl_option CYGDAT_ETHDRV_NAME {
	    display       "Name to use for this network device"
	    flavor        data
	    default_value { (1 == CYGHWR_NET_DRIVERS) ? "\"eth0\"" : "\"eth1\"" }
	    description "
	        The name of this network device for control purposes.
	    "
	}

        cdl_option CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH0 {
            display "Use 'eth0'"
            flavor bool
            implements CYGHWR_NET_DRIVER_ETH0
            calculated    { "\"eth0\"" == CYGDAT_ETHDRV_NAME }
            no_define
            description "Select this option to use the ethernet driver as eth0"
        }

        cdl_option CYGPKG_DEVS_ETH_ARM_EDB7XXX_NET_DRIVER_ETH1 {
            display "Use 'eth1'"
            flavor bool
            implements CYGHWR_NET_DRIVER_ETH1
            calculated    { "\"eth1\"" == CYGDAT_ETHDRV_NAME }
            no_define
            description "Select this option to use the ethernet driver as eth1"
        }

    cdl_component CYGPKG_DEVS_ETH_ARM_EDB7XXX_OPTIONS {
        display "Cirrus Logic ethernet driver build options"
        flavor  none
	no_define

        cdl_option CYGPKG_DEVS_ETH_ARM_EDB7XXX_CFLAGS_ADD {
            display "Additional compiler flags"
            flavor  data
            no_define
            default_value { "-D_KERNEL -D__ECOS" }
            description   "
                This option modifies the set of compiler flags for
                building the Cirrus Logic ethernet driver package.
                These flags are used in addition
                to the set of global flags."
        }
    }
}

RE: [ECOS] ethernet driver package idea

[Trenton D. Adams]

One more thing.  You might want to do what I've done below.  It's a
little nicer using a drop down box than a text box for selection of the
ethX device name!

	cdl_option CYGDAT_ETHDRV_NAME {
	    display       "Name to use for this network device"
	    flavor        data
          legal_values {"\"eth0\"" "\"eth1\""}
	    default_value { (1 == CYGHWR_NET_DRIVERS) ? "\"eth0\"" :
"\"eth1\"" }
	    description "
	        The name of this network device for control purposes.
	    "
	}


-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Trenton D.
Adams
Sent: Friday, August 24, 2001 9:47 AM
To: bartv@redhat.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: RE: [ECOS] ethernet driver package idea


We are going to have two interfaces on our board.  The cs8900 and the
Wavelan PC card.  So, this option is helpful because I can change them
to any device I want without going and editing the CDL and source.

The new CDL is attached if you want to incorporate it.

ETH_DRV_SC(edb7xxx_sc,
           &_cs8900_priv_data, // Driver specific data
           CYGDAT_ETHDRV_NAME,             // Name for this interface
           cs8900_start,
           cs8900_stop,
           cs8900_control,
           cs8900_can_send,
           cs8900_send,
           cs8900_recv,
           cs8900_deliver,     // "pseudoDSR" called from fast net
thread
           cs8900_int,         // poll function, encapsulates ISR and
DSR
           cs8900_int_vector);

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com
[ mailto:ecos-discuss-owner@sources.redhat.com ] On Behalf Of Bart Veer
Sent: Friday, August 24, 2001 9:42 AM
To: tadams@theone.dnsalias.com
Cc: ecos-discuss@sourceware.cygnus.com
Subject: Re: [ECOS] ethernet driver package idea


>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> But this is only done on the USB interface then?

When an ethernet driver is likely to be the only one present on a
given target then it can just default to eth0 - in most circumstances
that will work just fine. For example, if the processor has a single
on-chip ethernet device then usually that will be the only ethernet
device in the target system.

The USB ethernet device is different, in that it has no way of
guessing whether or not another ethernet device is present. Hence it
has more complicated CDL which makes sure that the right thing
happens: if it provides the only ethernet interface in the system then
it will use eth0; if there is a real ethernet device then that can
stay as eth0 and the USB-ethernet will become eth1.

For something like a driver for a PCMCIA plugin card, much the same
applies. That driver has no way of knowing whether or not another
ethernet device is present on the target hardware, so it should adapt. 

    Trenton> Doing it the way I did it wouldn't require an update of
    Trenton> the config tool though! Also, do you have the new tool
    Trenton> ready for download? I personally don't have the time at
    Trenton> the moment to install wxWindows, and then recompile the
    Trenton> tool. If anything goes wrong, it's wasted my employer's
    Trenton> money, and I don't want to do that.

    Trenton> Besides, yours seems to work with the Windows GUI config
    Trenton> tool 2.04. I can't be sure because I don't have two
    Trenton> ethernet interfaces to check it with. Is the conflict
    Trenton> resolution thing the only problem with it?

I do not know offhand whether 2.04 includes the required libcdl
changes, that is why I included the libcdl ChangeLog entry. If 2.04
was built before 2001-07-10 then it cannot have the required changes.
If it was built after 2001-07-10 then it almost certainly does have
the required changes. Take a look at Help->About to find out when the
configtool was built. The libcdl changes were specifically to cope
with targets that already have an ethernet interface and you are now
adding a second one such as USB-ethernet.

Bart

Re: [ECOS] ethernet driver package idea

[Bart Veer]

>>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:

    Trenton> One more thing. You might want to do what I've done
    Trenton> below. It's a little nicer using a drop down box than a
    Trenton> text box for selection of the ethX device name!

    Trenton> 	cdl_option CYGDAT_ETHDRV_NAME {
    Trenton> 	    display       "Name to use for this network device"
    Trenton> 	    flavor        data
    Trenton>           legal_values {"\"eth0\"" "\"eth1\""}
    Trenton> 	    default_value { (1 == CYGHWR_NET_DRIVERS) ? "\"eth0\"" :
    Trenton> "\"eth1\"" }
    Trenton> 	    description "
    Trenton> 	        The name of this network device for control purposes.
    Trenton> 	    "
    Trenton> 	}

This would prevent the user from calling the device something other
than eth0 or eth1, effectively restricting the system to just two
ethernet devices. It is possible to have more than that, although at
present only eth0 and eth1 can be easily configured via the
configuration tool - any additional ones require effort at the
application level. I would prefer users to still have the flexibility
to call their network devices anything they want to, even if this
involves a bit more complexity in the user interface.

Bart

Re: [ECOS] ethernet driver package idea

[Jonathan Larmour]

Bart Veer wrote:
> 
> >>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:
> 
>     Trenton> One more thing. You might want to do what I've done
>     Trenton> below. It's a little nicer using a drop down box than a
>     Trenton> text box for selection of the ethX device name!
> 
>     Trenton>    cdl_option CYGDAT_ETHDRV_NAME {
>     Trenton>        display       "Name to use for this network device"
>     Trenton>        flavor        data
>     Trenton>           legal_values {"\"eth0\"" "\"eth1\""}
>     Trenton>        default_value { (1 == CYGHWR_NET_DRIVERS) ? "\"eth0\"" :
>     Trenton> "\"eth1\"" }
>     Trenton>        description "
>     Trenton>            The name of this network device for control purposes.
>     Trenton>        "
>     Trenton>    }
> 
> This would prevent the user from calling the device something other
> than eth0 or eth1, effectively restricting the system to just two
> ethernet devices. It is possible to have more than that, although at
> present only eth0 and eth1 can be easily configured via the
> configuration tool - any additional ones require effort at the
> application level. I would prefer users to still have the flexibility
> to call their network devices anything they want to, even if this
> involves a bit more complexity in the user interface.

I'm not sure this is a reasonable concern given the hardwiring of the
interface names in init_all_network_interfaces(). We should be able to do
better here, but it's more than a few minutes work. Volunteers?

But in any case I think it's irrelevant for the case in hand - the cs8900
is on-board all the time, and any PC cards won't be, implying the cs8900
should always be eth0 on the edb7xxx, and any optional card eth1, and not
the other way round. I don't know why Trenton would want it to be more
changeable than that. If Trenton wants to just swap them, I'd recommend he
just hack it. I still don't think it's an appropriate default for others.

It'll be more fun when we have more than one non-permanently attached
device.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] ethernet driver package idea

[Hugo Tyson]

Jonathan Larmour <jlarmour@redhat.com> writes:
> Bart Veer wrote:
> > 
> > >>>>> "Trenton" == Trenton D Adams <tadams@theone.dnsalias.com> writes:
> > 
> >     Trenton> One more thing. You might want to do what I've done
> >     Trenton> below. It's a little nicer using a drop down box than a
> >     Trenton> text box for selection of the ethX device name!
> > 
> >     Trenton>    cdl_option CYGDAT_ETHDRV_NAME {
> >     Trenton>        display       "Name to use for this network device"
> >     Trenton>        flavor        data
> >     Trenton>           legal_values {"\"eth0\"" "\"eth1\""}
> >     Trenton>        default_value { (1 == CYGHWR_NET_DRIVERS) ? "\"eth0\"" :
> >     Trenton> "\"eth1\"" }
> >     Trenton>        description "
> >     Trenton>            The name of this network device for control purposes.
> >     Trenton>        "
> >     Trenton>    }
> > 
> > This would prevent the user from calling the device something other
> > than eth0 or eth1, effectively restricting the system to just two
> > ethernet devices. It is possible to have more than that, although at
> > present only eth0 and eth1 can be easily configured via the
> > configuration tool - any additional ones require effort at the
> > application level. I would prefer users to still have the flexibility
> > to call their network devices anything they want to, even if this
> > involves a bit more complexity in the user interface.
> 
> I'm not sure this is a reasonable concern given the hardwiring of the
> interface names in init_all_network_interfaces(). We should be able to do

init_all_network_interfaces() is *example* code, intended for use mainly by
our own default testcases, remember.  People with more or different
interface lists should write a variant on it.

> better here, but it's more than a few minutes work. Volunteers?

I believe that general problem requires some hypothetical Hardware
Configuration Tool (to generate and catenate code fragments to initialize
extra hardware) and/or C-preprocessor looping directives, neither of which
are scheduled to appear any time soon.

Anyway, restricting interface names even to eth%1d isn't really acceptable,
though it's a neat bit of CDL, for sure.

	- Huge