On Sun, 12 Aug 2007, [EMAIL PROTECTED] wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d822865..fc87fa7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4764,6 +4764,7 @@ L: linux-usb-devel
On Sun, 29 Jul 2007, Oliver Neukum wrote:
Am Sonntag 29 Juli 2007 schrieb Jesper Juhl:
On 29/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
Hi,
On 7/29/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
Hello,
This patch makes sure we don't dereference a NULL pointer in
drivers/net/usb/pegasus.c::
The patch looks good to me. Thanks.
Petko
On Sun, 3 Dec 2006, Oliver Neukum wrote:
> Hi,
>
> this is a conservative port of a 2.6 fix for the pegasus driver which leaks
> TASK_UNINTERRUPTIBLE in error cases. In case of an error the state
> needs to be reset to TASK_RUNNING.
>
Thanks for the patch. I don't think this device and vendor ID has ever
been submitted.
Petko
On Tue, 28 Nov 2006, [EMAIL PROTECTED] wrote:
> Hi,
>
> I am using the rtl8150 driver included in kernel version 2.6.17 with my OQO
> however I needed to add the vendor ID for this c
+0300
+++ /home/petkan/src/pegasus/v2.6/pegasus.c 2006-09-27 18:51:43.0
+0300
@@ -45,7 +45,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.6.13 (2005/11/13)"
+#define DRIVER_VERSION "v0.6.14 (2006/09/27)"
#define DRIVER_AUTHOR "Petko Manolov &
There's indeed such problem. I'm working on it and will submit the patch
as soon as i fix it.
Petko
On Fri, 8 Sep 2006, Andrew Morton wrote:
>
>
> Begin forwarded message:
>
> Date: Fri, 8 Sep 2006 12:42:39 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [
ion */
-#define DRIVER_VERSION "v0.6.2 (2004/08/27)"
+#define DRIVER_VERSION "v0.6.3 (2006/07/27)"
#define DRIVER_AUTHOR "Petko Manolov <[EMAIL PROTECTED]>"
#define DRIVER_DESC "rtl8150 based usb-ethernet driver"
@@ -173,6 +173,8 @@
static voi
Hey Greg,
Do you want me to send you another patch or this one's good enough?
cheers,
Petko
On Wed, 5 Jul 2006, Dan Streetman wrote:
> Hi,
>
> I just got a "ZyXEL Prestige USB Adapter" that is actually RTL8150
> adapter. Here is the relevant /proc/bus/usb/devices output (after
> add
ok, looks all right to me.
Petko
On Sat, 2 Jul 2005, Adrian Bunk wrote:
The only uses of both variables were recently removed.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/net/pegasus.c |1 -
drivers/usb/net/rtl8150.c |2 --
2 files changed, 3 dele
On Mon, 21 Mar 2005, David Brownell wrote:
This does what $SUBJECT says, plus a bit more ... I got tired of
the old-school messaging, and went new school!There are also
a few other fixes merged in here, sparse and some cleanups.
The only thing i think is redundant here is checking the return va
That's reasonable. Thanks for the patch.
Petko
On Tue, 1 Mar 2005, Adrian Bunk wrote:
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/usb/net/pegasus.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
--- l
rking for me and the latest
gregkh-2.6 tree. Hope this time it'll compile. :-)
Petko
On Thu, Feb 03, 2005 at 06:20:38PM +0200, Petko Manolov wrote:
Hi Greg,
When the bonding driver attempts to read the link status via
xxx_get_settings() the enslaved usb-eth driver crash the kernel. W
MAIL PROTECTED], 2005-02-03 18:07:07+02:00, [EMAIL PROTECTED]
changes mainly include adding work queue to both drivers
and a bunch of other small fixes.
Signed-off-by: Petko Manolov <[EMAIL PROTECTED]>
pegasus.c | 61 +
rtl8150.c | 127 ++
On Thu, 13 Jan 2005, Mike Nix wrote:
pegasus->phy = 1;
}
+ pegasus->mii.phy_id = pegasus->phy;
usb_set_intfdata(intf, pegasus);
SET_NETDEV_DEV(net, &intf->dev);
pegasus_reset_wol(net);
---
Definitly a good idea to set that - although nothing in
On Thu, 13 Jan 2005, Mike Nix wrote:
I tested this by calling it from enable_net_traffic so that carrier was
checked whenever the interface was configured "up" - I then ran
"ifconfig eth2 down;ifconfig eth2 up" inserting / removing the cable
between runs - carrier was reported correctly every tim
by Kconfig;
* updated the version string;
Signed-off-by: Petko Manolov <[EMAIL PROTECTED]>
pegasus.c | 204 ++
pegasus.h |3
2 files changed, 117 insertions(+), 90 deletions(-)
diff -Nru a/drivers/usb/net/pega
On Thu, 13 Jan 2005, Petko Manolov wrote:
On Wed, 12 Jan 2005, David Brownell wrote:
No -- CONFIG_BRIDGE. The "brctl" tool just administers the
kernel infrastructure for 802.1d bridging. There's not even
a kernel task associated with it, much less a userspace one.
Well, any rea
On Wed, 12 Jan 2005, David Brownell wrote:
No -- CONFIG_BRIDGE. The "brctl" tool just administers the
kernel infrastructure for 802.1d bridging. There's not even
a kernel task associated with it, much less a userspace one.
Well, any reading of the PHY should go through the pegasus driver. Since
On Wed, 12 Jan 2005, David Brownell wrote:
Sounds like the theory I was ending up with ... :)
What a coincidence.. ;-)
The bridge code was able to detect the link coming back up, as if
maybe it were talking directly to the MII and not needing to rely
You mean the user level code running on the same
On Wed, 12 Jan 2005, David Brownell wrote:
You're the maintainer, so it'd be good if you added Signed-off-by and
forwarded it to him.
OK.
Mike Nix confirmed it resolved the bridging issue for him too, but
reported some problems detecting carrier loss. Does that ring any
bells for you? I found the
Thanks Dave, very exhaustive patch description. :-)
Played wiht it in the morning and seems that the is working fine. Will
you send the patch to Greg or i do this?
Petko
On Tue, 11 Jan 2005, David Brownell wrote:
I ran into http://bugme.osdl.org/show_bug.cgi?id=3978 a while back, did
there!
>
> On 2004.01.07, I posted a trivial patch, that added one vendor/product
> id pair to the pegasus driver.
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg18623.html
> The maintainer of the driver, Petko Manolov <[EMAIL PROTECTED]>
> answered "Applied, t
Applied, thanks.
Petko
On Wed, 7 Jan 2004, Csillag Kristof wrote:
> [PATCH] USB: pegasus driver update
>
> [Please CC to me, I'm not subscribed to linux-usb-devel]
>
> Hi there!
>
> After some research (actually, from studying the INF files which I
> extracted from the downloa
Hi there,
On Fri, 26 Dec 2003, Dimitri Torfs wrote:
> "Chip" identification of the pegasus driver does not work correctly on
> big endian machines, resulting in incorrect packet lengths for
> received ethernet packets. These patches (against 2.4.24-pre2 and
> 2.6.0) should fix it.
On Wed, 6 Aug 2003, Oliver Neukum wrote:
> Am Mittwoch, 6. August 2003 08:24 schrieb Petko Manolov:
> > On Wed, 6 Aug 2003, Oliver Neukum wrote:
> >
> > > GFP_DMA has no place in USB drivers, as its meaning is inconsistent
> > > across architectures.
> >
On Wed, 6 Aug 2003, Oliver Neukum wrote:
> DMA to a part of a structure is forbidden on the noncoherent architectures.
Didn't quite get this. What "noncoherent" is supposed to mean here? In
general the memory allocated for a structure which is part of the
kernel (or kernel module) should be as
On Wed, 6 Aug 2003, Oliver Neukum wrote:
> GFP_DMA has no place in USB drivers, as its meaning is inconsistent
> across architectures.
The patch looks ok to me, although GFP_DMA used to mean that the allocated
memory will be contiguous and taken from the dma-able memory. If this is
no longer nee
On Wed, 6 Aug 2003, Oliver Neukum wrote:
> Am Mittwoch, 6. August 2003 08:30 schrieb Petko Manolov:
> > On Wed, 6 Aug 2003, Oliver Neukum wrote:
> >
> > > DMA to a part of a structure is forbidden on the noncoherent architectures.
> >
> > Didn't quite get
On Sat, 7 Jun 2003, David Brownell wrote:
> Jeff Garzik wrote:
> >>
> >>strlcpy?
> >
> >
> > No need, when the length is obviously less.
>
> True, not "necessary" in this case ... but it's still
> IMO a much better practice. And if we're serious about
> rubbing out that family of bugs, we'll just
On Fri, 6 Jun 2003, Jeff Garzik wrote:
> Olaf Hering wrote:
> > Hi,
> >
> > ethtool -i ethX should return the driver name instead of a 'verbose'
> > string. Other tools rely on the output.
> > 2.5 might need a similar fix.
> >
> > smirnow:~ # ethtool -i eth0
> > driver: 3c59x
> > version: LK1.1.16
d, 174 insertions(+), 217 deletions(-)
diff -Nru a/drivers/usb/rtl8150.c b/drivers/usb/rtl8150.c
--- a/drivers/usb/rtl8150.c Mon Jul 22 22:56:59 2002
+++ b/drivers/usb/rtl8150.c Mon Jul 22 22:56:59 2002
@@ -1,11 +1,9 @@
/*
- * Copyright (c) 2002 Petko Manolov ([EMAIL PROTECTED])
- *
> The following check seems redundant:
>
> static void * rtl8150_probe(struct usb_device *udev, unsigned int ifnum,
> const struct usb_device_id *id)
> {
> ..
> if ((udev->descriptor.idVendor != VENDOR_ID_REALTEK) ||
> (udev->descriptor.idProduct
> On Thu, Apr 25, 2002 at 10:50:30PM -0700, David Brownell wrote:
>> Please merge to Linus' tree, unless Petko has some other fix
>> he'd prefer.
>
> I'll wait for Petko to let me know if he likes this patch or not.
Hi Greg,
the patch looks good to me. I am in Europe right now and
i'll
Oliver Neukum wrote:
> And from the tasklet. Let's suppose that the atomic pool is depleted
> and submission fails. The tasklet is scheduled. Unless another tasklet
> or interrupt frees the right kind of memory the tasklet will keep
> rescheduling itself.
That's what we want, isn't it?
> Yes, you are right.
> Next issue. What prevents you from burning all available CPU ?
The tasklet is rescheduled unconditionaly only from the Rx callback.
No Rx packets, no overkill.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use th
Oliver Neukum wrote:
> On Friday 12 April 2002 20:01, Petko Manolov wrote:
>
> pool, the tasklet will not be scheduled a second time, as
> only the completion handler will reliably schedule the tasklet.
Fixed.
> 5. You do not lock against concurrent tasklets. IMHO with sufficie
> 3. The handling for errors in urb->status in the rx path looks fishy.
> There's a code path in which you don't schedule the tasklet.
It turned out returning on -ENOENT is the right thing. This error code
mean the urb is in unlink stage and no action is required. :-)
Petko
_
> IMHO draining the pool about 50% and then refill it in
> one go would be much more efficient.
The pool doesn't change the efficiency. At all. I tested the driver
with and without rx skb cache and there was no difference. Looks like
the bottleneck is in the usb bus itself, not in the memory a
Oliver Neukum wrote:
> On Friday 12 April 2002 02:44, you wrote:
>
>>OK, this is the final patch which should cover the case we are
>>low on memory and if usb_submit_urb() fail. Comments?
>
>
> I'd like to see the patch. Would you please include it ? ;-)
Here we go again. :-)
Petko Manolov wrote:
> Oliver Neukum wrote:
>
>> The tasklet will safe you if you could not allocate rx_skb.
>> It will not safe you if usb_submit_urb() itself fails.
OK, this is the final patch which should cover the case we are
low on memory and if usb_submit_urb
Oliver Neukum wrote:
> The tasklet will safe you if you could not allocate rx_skb.
> It will not safe you if usb_submit_urb() itself fails.
True. Working on this.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field a
> the rx urb twice, in the completion handler and in the tasklet ?
Ahum, no. Rx urb is resubmited only if there is available sk_buff
_and_ default Rx urb (dev->rx_urb) == NULL. Which is the right thing
to do. Instead I've found possible memory leak in rx_fixup after
looking at ti closely. :-)
David Brownell wrote:
>
> Although this does make me wonder if I should expose the individual
> types of device supported by "usbnet" as separate CONFIG_ options.
> Support for some of them is more robust/complete than for others.
> Comments?
As Greg said this should be up to you. :-)
> It's up to the driver's author to take CONFIG_EXPERIMENTAL off of it.
> I'll gladly take a patch from them to remove it.
Here is the patch. I pulled out 3 devices from the experimental list
which i am sure are quite mature. There may be more so if the authors
may add some more if they feel li
Oliver Neukum wrote:
>
> OK, I found it. The whole subsection depends on CONFIG_EXPERIMENTAL.
Oh, well. Some of the drivers are quite stable so i thing they could
be excluded from the experimental list. Namely kaweth, usbnet,
pegasus...
Greg, what do you think?
Petkan
_
>>>in Greg's last 2.5 kernel I can't select any usb network
>>>devices. Is this just me ?
>>
>>Do you get a "Networking support is needed for USB Networking device
>>support" message? Or just nothing for the network devices?
>
>
> In menuconfig just nothing.
> I do have a Config.in in drivers/u
> Some of the HCDs have been known to reference URBs
> after they issue the "it's unlinked now" callback, which is
> bogus (if it's unlinked, the _driver_ owns the URB!) but for
> now you have to live with it. I've freed them in a tasklet; I
> think only "usb-uhci" was particuarly problematic. T
>> in static int write_mii_word(rtl8150_t *dev, u8 phy, __u8 indx, u16 reg)
>> you are using HZ which is architecture dependend.
>
>
> HZ value is used in usb_start_wait_urb() and is passed to
Oops! I misunderstood this - you're talking about [read|write]_mii_word
You are right. Fixed. Thank
> in probe() you'll do a double free, if allocating
Hm, good catch. It is now fixed. Thanks.
> free allocated urbs in the error case, but set the
> pointers of the device descriptor to NULL.
Why? If alloc_all_urbs() fail we're exiting _probe() with error
code and nothing more happens.
> in static void ctrl_callback(struct urb *urb) you are using
> clean_bit on an usigned int. On some architectures this will
> bomb. You need to define flags as unsigned long.
flags field is not used for signed arithmetic (only the least
significant bits are used anyway). How this could possibl
> And then please put them back again when Adam rereads the code 8)
I haven't deleted them and i am not planing to after all this traffic. :-)
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sour
> Its done for alignment rather than DMA. On a non x86 box many unaligned
> accesses are extremely expensive. Doing the 2 byte shuffle lands the IP
> header on a 4byte aligned address
Isn't it better if the alignment is done by default by alloc_skb and
let the driver writer to take care the futur
> I don't know what you are referring to above. You should keep
> the line that says "dev->rx_skb->dev = netdev;" I just want you to
> delete both lines that say "skb_reserve(dev->rx_skb, 2);"
This is harmless. What it does is to move the beginning and the end
of the data field with 2 by
> - delete the unused variable rtl8150.interface
> (never set and never used)
Done. It remained from usb-skeleton. :-)
> - comment out the unused variable rx_stat in read_bulk_callback
> (it is set, but never used)
This is not used ye
Adam J. Richter wrote:
> You should also delete the line that calls skb_reserve.
I think it should be there. Otherwise the first time read_bulk_callback
is called the socket buffer will not be attached to the appropriate
device neither the padding 2 bytes will be reserved.
Or you have some
58:16 2002
@@ -21,14 +21,11 @@
#include
#include
-
-
/* Version Information */
-#define DRIVER_VERSION "v0.5.0 (2002/03/28)"
+#define DRIVER_VERSION "v0.5.2 (2002/04/05)"
#define DRIVER_AUTHOR "Petko Manolov <[EMAIL PROTECTED]>"
#define DRIVER_DESC &qu
> For the record, "usbnet" has done this quite successfully for some
> time now. It was a design goal in fact; at this point only one of the
> framing schemes risks extra TX copies, and none do it on the RX
> path. It'd be a Good Thing if all of the drivers/usb/net/*.c code
> avoided needless co
Adam J. Richter wrote:
> The USB ethernet driver in linux-2.5.8-pre1/drivers/usb/rtl8150.c
> unnecessarily copies all transmitted and received packets. The following
> patch eliminates copying of both transmitted and received packets.
> I am running the resulting driver now and it seems
Oliver Neukum wrote:
> On Wednesday 03 April 2002 20:21, you wrote:
>
drivers/usb will have the following subdirectories:
class/ all USB class drivers
controller/ all USB device controller drivers
core/ the USB core code (both for devices and hos
>>drivers/usb will have the following subdirectories:
>> class/ all USB class drivers
>> controller/ all USB device controller drivers
>> core/ the USB core code (both for devices and hosts)
>> fs/ usbfs code
>> host/ all USB ho
Johannes Erdfelt wrote:
>
> I understand that when it receives a 0 packet, it handles the packet
> correctly, but does it *send* a 0 packet when it's transferring to the
It is not mentioned anywhere in the documentation, and i don't get
packets with 0 length from the device. I have code which w
Johannes Erdfelt wrote:
> When they say "host" do they mean the PC running Linux or the ethernet
> device?
They mean the usb-eth device. The documentation is just crap. :-(
> Sometimes, they don't take into consideration blocks of data that are
> multiples of the endpoint size and thusly, requi
> When the packet size is a multiple of the endpoint size, does it send a
> zero packet?
I couldn't find this in the documentation. It says the host treats
pakect smaller than 64 bytes or equal zero as the end of ethernet
packet and that's all.
> I wonder if it's sending two packets as one and
> I suspect it's 1. What ethernet device is this with? What driver?
Could be. This is new driver - rtl8150. You should checkout Greg's
BK tree to get it or browse the CVS repository at:
http://pegasus2.sourceforge.net/
The device is quite similar to pegasus/pegasusII and i've tried a lot
of co
Hi,
I ran into a weird problem with one of the usb devices i have around.
When a long (ethernet ~1000 bytes) packet hit the wire the read urb
return error -75 (supposedly TD_CTRL_BABBLE). What could be the source
of this problem? Small packets are going back and forth without problem
ev
Greg KH wrote:
> made the change and go complain to them. However, 99% of the time
> you are usually very glad that the change was made, and you should
> not mind that other people are fixing your code.
I don't mind when the api change and somebody make the driver compile.
It did happen people c
Nemosoft Unv. wrote:
>
> AND IF PEOPLE WOULD CC: ME PATCHES WHEN THEY MODIFY MY SOURCE I WOULD AT
> LEAST HAVE AN IDEA THAT SOMETHING'S GOING ON!
Except for the yell he's damn right. Sometimes i've found my driver
quite changed and no one even bother to CC. Hopefully (in my case) most
of that
> Why not just use the proper __attribute__((aligned(L1_CACHE_BYTES)))
> statement within the structures, or use the L1_CACHE_ALIGN macro which
> is defined in cache.h?
This patch is outdated. I removed the macro. Greg and Linus already
applied the changes. It makes _no_ difference if we are t
> Specific uses (or rules of thumb ;-) ):
> -start_xmit and timeout methods of network drivers must use GFP_ATOMIC (spinlock)
You can add receive routines here as well.
Petko
___
[EMAIL PROTECTED]
To unsubscribe, use the last form
> pegasus_tx_timeout() unlinks the tx_urb asynchronously, as it must.
> However pegasus_start_xmit() uses this urb without checking
> for the unlinking having been done.
The upper layer will not send any packets downstream (i.e.
call pegasus_start_xmit()) because netif_wake_queue() is called
onl
01/12/07)"
+#define DRIVER_VERSION "v0.4.23 (2002/02/01)"
#define DRIVER_AUTHOR "Petko Manolov <[EMAIL PROTECTED]>"
#define DRIVER_DESC "Pegasus/Pegasus II USB Ethernet driver"
@@ -94,7 +94,7 @@
static int update_eth_regs_async( pegasus_t * );
/* Aargh!
Hi Greg,
will you please use this pegasus.c.diff instead of the previous
one... another memory leak was found by Oliver.
It is funny how such a small driver can leak so much :-)
Petko
Petko Manolov wrote:
> Hi Greg,
>
> two things this time:
>
> it seems that pegasus_probe() has a memory leak in the error case and
> pegasus_disconnect() fails to unlink urbs before it frees them.
These urbs used to be staticly allocated and i don't really know
why Greg changed them to dynamicly allocated not so long ago.
I guess the answer is somewhere
/pegasus.c.orig Fri Feb 1 15:02:38 2002
+++ linux/drivers/usb/pegasus.c Fri Feb 1 15:09:25 2002
@@ -53,7 +53,7 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.4.22 (2001/12/07)"
+#define DRIVER_VERSION "v0.4.23 (2002/02/01)"
#define DRIVER_AUTHOR "Petko
Hi,
the patch looks good. I'll give it a paranoia try and then send it to
Linus and Marcelo.
Petko
Chris Rankin wrote:
> Hi,
>
> I have noticed that the Pegasus II driver in the Linux 2.4.16 kernel
> uses the old Linux 2.2-style module locking. I have attached a pa
> 1. You use interruptible_sleep_on in get_registers() which could potentially
> lose a wakeup.
Right. Now i am using the timeout version of the call. For now it seems
it works.
> 2. There is no need to check a waitqueue for waiters. Simply wake them up
> unconditionally.
I am afraid this could
+++ linux/drivers/usb/pegasus.c Tue Jun 12 19:02:04 2001
@@ -53,8 +53,8 @@
/*
* Version Information
*/
-#define DRIVER_VERSION "v0.4.18 2001/03/18 (C) 1999-2000"
-#define DRIVER_AUTHOR "Petko Manolov <[EMAIL PROTECTED]>"
+#define DRIVER_VERSION "v0.4.19 2001/06/07 (C)
Hi Oliver,
Good spot. Thanks.
The control transfers are not used very often so this bug remained
hidden for so long. This patch hopefully fix it plus one more.
Comments?
later,
Petko
--- Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Hi Petkan, hi list,
>
> I believe there's a race tha
The patch is already in 2.4.3-pre5 and 6
I tested it and it didn't fail for me. If what
Roman said is true the patch make sense.
However it doesn't hurt :-)
Petko
> -Original Message-
> From: David Brownell [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 6:51 PM
> To: [
79 matches
Mail list logo
