Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r linux-2.4.0-test13-pre1.clean/Documentation/Configure.help
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r linux-2.4.0-test13-pre1.clean/Documentation/Configure.help
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
---
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
---
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
---
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/Documentation/Configure.help
linux-2.4.0-test11.fs50/Documentation/Configure.help
---
Bartlomiej Zolnierkiewicz wrote:
> You may also consider processing firestream.[ch] through indent because
> spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
> be nice too have tabs everywhere).
As far as I know the tabs/spaces are exactly the way I want them.
There are
Hi!
Just a few hints on __init/__exit stuff...
On Wed, 22 Nov 2000, Patrick van de Lageweg wrote:
> +struct reginit_item PHY_NTC_INIT[] = {
Can be marked __initdata
> +void undocumented_pci_fix (struct pci_dev *pdev)
Can be marked __init
> +void write_phy (struct fs_dev *dev, int regnum,
[Rogier Wolff]
> > > +MODULE_PARM(fs_debug, "i");
> >
> > There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
> anymore in 2.4
^^^2.2
Verified in 2.2.0 (the oldest tree I have).
Peter
-
To unsubscribe from this
Mitchell Blank Jr wrote:
> * I don't like header files that define the registers of the chip - since
> the header file is only included in the driver's .c
For a non-hypothetical case why it makes sense to have such things in
their own header file: if you dig out some older versions of the
Mitchell Blank Jr wrote:
> > +MODULE_PARM(fs_debug, "i");
>
> There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
anymore in 2.4
OK.
> > +#define MIN(a,b) (((a)<(b))?(a):(b))
>
> You don't seem to ever use this definition.
H. Used to
On Thu, Nov 23, 2000 at 09:22:09AM +0100, Rogier Wolff wrote:
> Peter Samuelson wrote:
>
> > > +int loopback = 0;
> > > +int fs_debug = 0;
> > > +struct fs_dev *fs_boards = NULL;
>
> > Aside from the 'static' issue already mentioned, these should be left
> > uninitialized. ('gcc
[Rogier Wolff <[EMAIL PROTECTED]>]
> However, if my code assumes that the compiler needs to initialize the
kernel
> variable one way or another, I want to put in the initialization,
> even if that means an "= 0;" which is already the default.
Well,
Peter Samuelson wrote:
> > +int loopback = 0;
> > +int fs_debug = 0;
> > +struct fs_dev *fs_boards = NULL;
> Aside from the 'static' issue already mentioned, these should be left
> uninitialized. ('gcc -fassume-bss-zero' would be nice, but then again
> in userspace it rarely matters.)
Hi
Peter Samuelson wrote:
+int loopback = 0;
+int fs_debug = 0;
+struct fs_dev *fs_boards = NULL;
Aside from the 'static' issue already mentioned, these should be left
uninitialized. ('gcc -fassume-bss-zero' would be nice, but then again
in userspace it rarely matters.)
Hi Peter,
[Rogier Wolff [EMAIL PROTECTED]]
However, if my code assumes that the compiler needs to initialize the
kernel
variable one way or another, I want to put in the initialization,
even if that means an "= 0;" which is already the default.
Well, your
On Thu, Nov 23, 2000 at 09:22:09AM +0100, Rogier Wolff wrote:
Peter Samuelson wrote:
+int loopback = 0;
+int fs_debug = 0;
+struct fs_dev *fs_boards = NULL;
Aside from the 'static' issue already mentioned, these should be left
uninitialized. ('gcc -fassume-bss-zero' would be
Mitchell Blank Jr wrote:
+MODULE_PARM(fs_debug, "i");
There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
anymore in 2.4
OK.
+#define MIN(a,b) (((a)(b))?(a):(b))
You don't seem to ever use this definition.
H. Used to though.. ;-)
Mitchell Blank Jr wrote:
* I don't like header files that define the registers of the chip - since
the header file is only included in the driver's .c
For a non-hypothetical case why it makes sense to have such things in
their own header file: if you dig out some older versions of the
[Rogier Wolff]
+MODULE_PARM(fs_debug, "i");
There's no reason to wrap these "MODULE_PARM"s inside an "#ifdef MODULE".
anymore in 2.4
^^^2.2
Verified in 2.2.0 (the oldest tree I have).
Peter
-
To unsubscribe from this list: send
Bartlomiej Zolnierkiewicz wrote:
You may also consider processing firestream.[ch] through indent because
spacing is inconsistent - sometimes tabs, sometimes 8*space (it would
be nice too have tabs everywhere).
As far as I know the tabs/spaces are exactly the way I want them.
There are tabs
[Patrick van de Lageweg]
> diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
>linux-2.4.0-test11.fs50+atmrefcount/drivers/atm/firestream.c
Since you are submitting in the form of a source patch, you ought to
include the relevent bits of
drivers/atm/Makefile
Jes Sorensen wrote:
> I think the most important issue is when doing header files to make
> sure they go with the driver code and not in include/linux unless
> there really is a reason to expose them to user space. No reason to
> export register definitions for Ethernet cards down there.
Agreed,
> "Rogier" == Rogier Wolff <[EMAIL PROTECTED]> writes:
Rogier> Mitchell Blank Jr wrote:
>> First, I'd like to make a couple points about driver style that I'm
>> trying to move towards with the ATM drivers. You're free to take
>> them or leave them, but I want to eventually move the tree in
Mitchell Blank Jr wrote:
> First, I'd like to make a couple points about driver style that I'm trying
> to move towards with the ATM drivers. You're free to take them or leave
> them, but I want to eventually move the tree in this direction.
> * I don't like header files that define the
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers of the chip - since
the
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
Hi Linus,
This is the driver for the Fujitsu Firestream atm cards (fs50 and
fs155). Please consider including this driver in the tree.
Thanks
Patrick
diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers of the chip - since
the
Mitchell Blank Jr wrote:
First, I'd like to make a couple points about driver style that I'm trying
to move towards with the ATM drivers. You're free to take them or leave
them, but I want to eventually move the tree in this direction.
* I don't like header files that define the registers
"Rogier" == Rogier Wolff [EMAIL PROTECTED] writes:
Rogier Mitchell Blank Jr wrote:
First, I'd like to make a couple points about driver style that I'm
trying to move towards with the ATM drivers. You're free to take
them or leave them, but I want to eventually move the tree in this
Jes Sorensen wrote:
I think the most important issue is when doing header files to make
sure they go with the driver code and not in include/linux unless
there really is a reason to expose them to user space. No reason to
export register definitions for Ethernet cards down there.
Agreed,
[Patrick van de Lageweg]
diff -u -r --new-file linux-2.4.0-test11.clean/drivers/atm/firestream.c
linux-2.4.0-test11.fs50+atmrefcount/drivers/atm/firestream.c
Since you are submitting in the form of a source patch, you ought to
include the relevent bits of
drivers/atm/Makefile
35 matches
Mail list logo
