On 21-03-25 22:56:52, 'Qiheng Lin wrote:
> From: Qiheng Lin
>
> Remove duplicated include.
It is not duplicated so do not remove it. Go ahead and look carefully at the
code, please.
Petko
> Reported-by: Hulk Robot
> Signed-off-by: Qiheng Lin
> ---
> drivers/net/usb/pegasu
On 20-10-12 12:11:18, Joe Perches wrote:
> On Mon, 2020-10-12 at 15:02 -0400, Sasha Levin wrote:
> > From: Anant Thazhemadam
> >
> > [ Upstream commit f45a4248ea4cc13ed50618ff066849f9587226b2 ]
> >
> > When get_registers() fails in set_ethernet_addr(),the uninitialized
> > value of node_id gets
On 20-10-11 11:33:00, Joe Perches wrote:
> On Sun, 2020-10-11 at 10:59 -0700, Jakub Kicinski wrote:
> > On Sun, 11 Oct 2020 23:00:30 +0530 Anant Thazhemadam wrote:
> > > In set_ethernet_addr(), if get_registers() succeeds, the ethernet address
> > > that was read must be copied over. Otherwise, a r
On 20-10-02 17:35:25, Anant Thazhemadam wrote:
>
> Yes, this clears things up for me. I'll see to it that this gets done in a v3.
If set_ethernet_addr() fail, don't return error, but use eth_hw_addr_random()
instead to set random MAC address and continue with the probing.
You can take a look he
On 20-10-01 18:42:18, David Miller wrote:
> From: Petko Manolov
> Date: Tue, 29 Sep 2020 14:40:39 +0300
>
> > -static void set_ethernet_addr(pegasus_t *pegasus)
> > +static int set_ethernet_addr(pegasus_t *pegasus)
> > {
>
> You change this to return an &#x
sible
errors (or partial reads) returned by its helpers. This can potentially lead to
writing random data into device's MAC address registers.
Signed-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
On 20-10-01 01:59:25, Andrew Lunn wrote:
>
> The subject of this email thread is:
>
> Altera TSE driver not working in 100mbps mode
>
> Are you doing your testing at 1G or 100Mbps? I would suggest starting out at
> 1G if you can.
Well, this is the subject i used some time ago. It is related t
On 20-09-30 21:43:04, David Bilsby wrote:
>
> I've made some progress in integrating your TSE patches, in between doing my
> main work. I've managed to get the code into the later 5.4.44 kernel and
> compile without errors, however my initial attempts failed to configure the
> driver. In case it w
Fix a bug in set_ethernet_addr() which does not take into account possible
errors (or partial reads) returned by its helpers. This can potentially lead to
writing random data into device's MAC address registers.
Signed-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c
the above check
to:
if (ret == sizeof(node_id)) {
and fail in any other case. Apart from this minor detail the rest of the patch
looks good to me.
Acked-by: Petko Manolov
On 20-09-28 16:00:58, David Miller wrote:
> From: Petko Manolov Date: Sun, 27 Sep 2020
> 15:49:07 +0300
>
> > Re-sending these, now CC-ing the folks at linux-netdev.
>
> I can't apply these since the helpers do not exist in the networking tree.
Right, Greg was on
igned-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c | 61 ++-
1 file changed, 15 insertions(+), 46 deletions(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index e92cb51a2c77..26b4e48bf91f 100644
--- a/drivers/net/usb/pegasus.c
The old usb_control_msg() let the caller handle the error and also did not
account for partial reads. Since these are now considered harmful, move the
driver over to usb_control_msg_recv/send() calls.
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 32
series is converting Pegasus and
RTL8150 drivers to using the proper calls.
Petko Manolov (2):
net: pegasus: Use the new usb control message API.
net: rtl8150: Use the new usb control message API.
drivers/net/usb/pegasus.c | 61 ++-
drivers/net/usb/rtl8150
On 20-09-24 13:09:05, Oliver Neukum wrote:
> Am Mittwoch, den 23.09.2020, 17:48 +0300 schrieb Petko Manolov:
>
> > One possible fix is to add yet another argument to usb_control_msg_recv(),
> > which would be the GFP_XYZ flag to pass on to kmemdup(). Up to Greg, of
> >
On 20-09-23 12:22:37, Oliver Neukum wrote:
> Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
>
> Hi,
>
> > Many usage of usb_control_msg() do not have proper error check on return
> > value leaving scope for bugs on short reads. New usb_control_msg_recv()
> > and usb_control_msg_
On 20-09-17 21:29:41, David Bilsby wrote:
> On 17/09/2020 07:42, Petko Manolov wrote:
> > On 20-09-16 22:32:03, David Bilsby wrote:
> > > Hi
> > >
> > > Would you consider making the PhyLink modifications to the Altera TSE
> > > driver public as
On 20-09-16 22:32:03, David Bilsby wrote:
> Hi
>
> Would you consider making the PhyLink modifications to the Altera TSE driver
> public as this would be very useful for a board we have which uses an SFP PHY
> connected to the TSE core via I2C. Currently we are using a fibre SFP and
> fixing th
On 20-09-16 10:35:40, Anant Thazhemadam wrote:
> get_registers() copies whatever memory is written by the
> usb_control_msg() call even if the underlying urb call ends up failing.
Not true, memcpy() is only called if "ret" is positive.
> If get_registers() fails, or ends up reading 0 bytes, meani
On 20-09-16 08:22:27, Greg KH wrote:
> On Wed, Sep 16, 2020 at 10:35:40AM +0530, Anant Thazhemadam wrote:
> > get_registers() copies whatever memory is written by the
> > usb_control_msg() call even if the underlying urb call ends up failing.
> >
> > If get_registers() fails, or ends up reading 0
On 19-07-30 15:13:57, Denis Kirjanov wrote:
> get_registers() may fail with -ENOMEM and in this
> case we can read a garbage from the status variable tmp.
>
> Reported-by: syzbot+3499a83b2d062ae40...@syzkaller.appspotmail.com
> Signed-off-by: Denis Kirjanov
> ---
> drivers/net/usb/pegasus.c | 2
On 19-07-31 22:10:39, Petko Manolov wrote:
> On 19-07-30 15:13:57, Denis Kirjanov wrote:
> > get_registers() may fail with -ENOMEM and in this
> > case we can read a garbage from the status variable tmp.
> >
> > Reported-by: syzbot+3499a83b2d062ae40...@syzkaller.appspo
On 19-05-09 11:01:06, Oliver Neukum wrote:
> A bit of housekeeping switching the driver to the BIT()
> macro.
Looks good. I hope you've at least compiled the driver? :)
Acked-by: Petko Manolov
cheers,
Petko
> Signed-off-by: Oliver Neukum
> ---
> drivers/ne
On 19-01-18 02:06:49, YueHaibing wrote:
> From: Yue Haibing
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/usb/rtl8150.c: In function 'read_bulk_callback':
> drivers/net/usb/rtl8150.c:391:6: warning:
> variable 'rx_stat' set but not used [-Wunused-but-set-variable]
Good cat
On 17-04-07 10:17:39, Tobias Klauser wrote:
> Instead of using a private copy of struct net_device_stats in struct pegasus,
> use stats from struct net_device. Also remove the now unnecessary
> .ndo_get_stats function.
Looks OK to me.
Petko
> Cc: Petko Manolov
o be working fine on real hardware.
Acked-by: Petko Manolov
cheers,
Petko
> Signed-off-by: Philippe Reynes
> ---
> drivers/net/usb/pegasus.c | 14 --
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/usb/pegasus.c b/drivers/net/us
On 17-03-13 17:00:20, Petko Manolov wrote:
> On 17-03-12 23:16:25, Philippe Reynes wrote:
> > The ethtool api {get|set}_settings is deprecated. We move this driver to
> > new
> > api {get|set}_link_ksettings.
> >
> > As I don't have the hardware, I'
On 17-03-12 23:16:25, Philippe Reynes wrote:
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> As I don't have the hardware, I'd be very pleased if someone may test this
> patch.
I've got some old adapters around and will drop you
On 17-02-07 10:32:16, Steve Calfee wrote:
> On Mon, Feb 6, 2017 at 4:51 AM, Petko Manolov wrote:
> > On 17-02-06 09:28:22, Greg KH wrote:
> >> On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> >> > On 17-02-05 01:30:39, Greg KH wrote:
> >>
On 17-02-07 14:14:30, David Laight wrote:
> From: Petko Manolov
> > Sent: 07 February 2017 13:21
> ...
> > > > Would you consider what David proposed (usb_control_msg_with_malloc())
> > > > for 4.11,
> > > > for example? I for one will use somethi
On 17-02-07 14:01:02, Greg KH wrote:
> On Tue, Feb 07, 2017 at 02:53:24PM +0200, Petko Manolov wrote:
> > On 17-02-07 11:51:31, Greg KH wrote:
> > > On Tue, Feb 07, 2017 at 12:34:52PM +0200, Petko Manolov wrote:
> > > > On 17-02-06 16:25:20, Ben Hutchings wrote:
>
On 17-02-07 11:51:31, Greg KH wrote:
> On Tue, Feb 07, 2017 at 12:34:52PM +0200, Petko Manolov wrote:
> > On 17-02-06 16:25:20, Ben Hutchings wrote:
> > > On Mon, Feb 06, 2017 at 04:09:18PM +, David Laight wrote:
> > > > From: Ben Hutchings
> > > [...]
&g
On 17-02-07 11:45:06, Greg KH wrote:
> On Tue, Feb 07, 2017 at 12:24:12PM +0200, Petko Manolov wrote:
> > On 17-02-06 14:46:21, Johan Hovold wrote:
> > > On Mon, Feb 06, 2017 at 02:32:23PM +0100, Johan Hovold wrote:
> > > > On Mon, Feb 06, 2017 at 02:21:24PM +0100, Jo
On 17-02-06 16:25:20, Ben Hutchings wrote:
> On Mon, Feb 06, 2017 at 04:09:18PM +, David Laight wrote:
> > From: Ben Hutchings
> [...]
> > > + ret = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
> > > + RTL8150_REQ_GET_REGS, RTL8150_REQT_READ,
> > > +
On 17-02-06 14:46:21, Johan Hovold wrote:
> On Mon, Feb 06, 2017 at 02:32:23PM +0100, Johan Hovold wrote:
> > On Mon, Feb 06, 2017 at 02:21:24PM +0100, Johan Hovold wrote:
> > > On Mon, Feb 06, 2017 at 02:51:09PM +0200, Petko Manolov wrote:
> > > > On 17-02-06 09:28:2
On 17-02-06 09:28:22, Greg KH wrote:
> On Mon, Feb 06, 2017 at 10:14:44AM +0200, Petko Manolov wrote:
> > On 17-02-05 01:30:39, Greg KH wrote:
> > > On Sat, Feb 04, 2017 at 04:56:03PM +, Ben Hutchings wrote:
> > > > Allocating USB buffers on the stack
On 17-02-04 16:56:32, Ben Hutchings wrote:
> Allocating USB buffers on the stack is not portable, and no longer
> works on x86_64 (with VMAP_STACK enabled as per default).
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Ben Hutchings
> ---
> drivers/net/usb/rtl8150.c | 34 +
On 17-02-05 01:30:39, Greg KH wrote:
> On Sat, Feb 04, 2017 at 04:56:03PM +, Ben Hutchings wrote:
> > Allocating USB buffers on the stack is not portable, and no longer
> > works on x86_64 (with VMAP_STACK enabled as per default).
>
> It's never worked on other platforms, so these should go to
ere are fixed number of work items, explicit concurrency
>> limit is unnecessary here.
>>
>> Signed-off-by: Bhaktipriya Shridhar
>
>Acked-by: Tejun Heo
>
>Thanks.
Acked-by: Petko Manolov
cheers,
Petko
On 16-08-30 22:02:47, Bhaktipriya Shridhar wrote:
> The workqueue "pegasus_workqueue" queues a single work item per pegasus
> instance and hence it doesn't require execution ordering. Hence,
> alloc_workqueue has been used to replace the deprecated
> create_singlethread_workqueue instance.
>
> The
Guys, come on. This code is not dead. This code is executed every time an
ethernet packet is received. It takes care of various error statistics. More
importantly, it sends the actual (reported by the adapter) packet length to the
network layer along with the packet.
This patch removes skb_p
On 16-05-19 11:35:42, David Miller wrote:
> From: Heinrich Schuchardt
> Date: Wed, 18 May 2016 02:13:30 +0200
>
> > (!count || count < 4) is always true.
> > So let's remove the coding which is dead at least since 2005.
> >
> > Signed-off-by: Heinrich Schuchardt
>
> Applied.
David, the patch
On 16-05-18 20:40:51, Heinrich Schuchardt wrote:
> If !count is true, count < 4 is also true.
Yep, you're right. However, gcc optimizes away the first condition. What you
really got me to think about is whether 4 is the right number. I guess i shall
refer to the HW documentation.
On 16-05-18 09:15:40, Oliver Neukum wrote:
> On Tue, 2016-05-17 at 23:30 -0700, Guenter Roeck wrote:
> > On Wed, May 18, 2016 at 02:13:30AM +0200, Heinrich Schuchardt wrote:
> > > (!count || count < 4) is always true.
> >
> > Even if count >= 4 ?
>
> The check for !count is redundant, though. Gcc
On 16-05-18 02:13:30, Heinrich Schuchardt wrote:
> (!count || count < 4) is always true.
> So let's remove the coding which is dead at least since 2005.
You may want to reconsider the above statement. Just assume that 'count' is
typically between 56 and 1514 bytes.
Petko
> Si
ussion with Johannes Berg);
Petko Manolov (2):
pegasus: fixes URB buffer allocation size;
pegasus: fixes reported packet length
drivers/net/usb/pegasus.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.8.0.rc3
The default Pegasus setup was to append the status and CRC at the end of each
received packet. The status bits are used to update various stats, but CRC has
been ignored. The new default is to not append CRC at the end of RX packets.
Signed-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.
Reported-by: Lincoln Ramsay
Signed-off-by: Petko Ma
According to ADM851x docs the ethernet packet is appended with 4
bytes, not 8. Fixing this to report (hopefully) the right amount
of data.
Signed-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/pegasus.c b
days without any complaints from
the
kernel.
Changes since v1:
- split the patch in two parts;
- corrected the subject lines;
Petko Manolov (2):
pegasus: fixes URB buffer allocation size;
pegasus: fixes reported packet length
drivers/net/usb/pegasus.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.8.0.rc3
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.
Reported-by: Lincoln Ramsay
Signed-off-by: Petko Ma
ed out the ethernet
packet is appended with 4 bytes of status data. That's why we now
subtract 4 instead of 8 bytes from the reported packet length.
Reported-by: Lincoln Ramsay
Signed-off-by: Petko Manolov
---
drivers/net/usb/pegasus.c | 8
1 file changed, 4 insertions(+), 4 del
27;pkt_len -= 8' is again
hidden in the mists of time. There might have been a good reason to do so, but
multiple reads of the datasheet did not point me to any.
The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring
multiple gigabytes of data over a couple of days w
Hi,
I've no idea how this PEGASUS_MTU + 8 got in. Maybe somebody played games with
the skb alignment over the years.
I'm traveling right now so i'll look at the patch more closely when I get back.
At first glance it does look OK.
cheers,
Petko
On April 5, 2016 1:31:33 PM GMT+03:00, Linco
'devid' module parameter. The expected format is:
"device_name:vendor_id:device_id:flags"
but it turned out people often type:
"somename::0"
instead of:
"somename:::0"
which typically ends up dereferencing null pointer.
Signed
Signed-off-by: Lennert Buytenhek <[EMAIL PROTECTED]>
Cc: Petko Manolov <[EMAIL PROTECTED]>
--- linux-2.6.24-git7.orig/drivers/net/usb/rtl8150.c2008-01-24
23:58:37.0 +0100
+++ linux-2.6.24-git7/drivers/net/usb/rtl8150.c 2008-01-30 20:29:00.0
+0100
@@ -
Hi Jeff,
Attached you'll find a patch that is fixing a driver bug triggered when
malformed string is passed to the 'devid' module parameter. The expected
format is:
"device_name:vendor_id:device_id:flags"
but it turned out people often type:
"somename::0"
instead o
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:[EMAIL PROTECTED]
L: n
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::
ACK :-)
cheers,
Petko
On Mon, 23 Jul 2007, Micah Gruber wrote:
This patch fixes a potential null dereference bug where we dereference
pegasus before a null check. This patch simply moves the dereferencing after
the null check.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/dr
tained
@@ -3702,8 +3701,7 @@
USB PEGASUS DRIVER
P: Petko Manolov
M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
+L: netdev@vger.kernel.org
W: http://pegasus2.sourceforge.net/
S: Maintained
@@ -3717,8 +3715,7 @@
USB RTL8150 DRIVER
P: Petko Mano
Good man, I owe you a beer. :)
cheers,
Petko
On Wed, 25 Apr 2007, Dan Williams wrote:
Simplify pegasus carrier detection; rely only on the periodic MII
polling. Reverts pieces of c43c49bd61fdb9bb085ddafcaadb17d06f95ec43.
Signed-off-by: Dan Williams <[EMAIL PROTECTED]>
--- a/drivers/usb/n
On Wed, 25 Apr 2007, Dan Williams wrote:
On Wed, 2007-04-25 at 17:58 +0300, Petko Manolov wrote:
In general i agree with the reasoning below. However, isn't it better to
remove the code that sets carrier on/off in intr_callback()?
I'm fine with this; whatever makes carrier status
In general i agree with the reasoning below. However, isn't it better to
remove the code that sets carrier on/off in intr_callback()?
There's a reliable way of getting the link status by reading the MII.
After correct checking of the return value from read_mii_word(),
set_carrier() is what is
If this fixes the issue then what else can i say?.. ;-)
However, isn't it better to just change RTL8150_MTU to 1500 instead of
removing that line?
Petko
On Sun, 17 Sep 2006, Lennert Buytenhek wrote:
The rtl8150 (ethernet) driver uses a default MTU of 1540, which causes
al
Hi Ben,
What you have sent me is a bit of a puzzle.
Looking at the device's details i can see it is not RTL8150 based device,
but ADMtek's ADM8511. Both vendor and device IDs have been listed in
pegasus.c for a long long time.
Using rtl8150.c will not help at all since it talks to a
66 matches
Mail list logo
