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
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-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-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
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 16-11-17 09:56:00, David Howells wrote:
> Petko Manolov wrote:
>
> > On 16-11-16 18:11:13, David Howells wrote:
> > > Allow keys to be added to the system secondary certificates keyring
> > > during
> > > kernel initialisation in an unrestricted fa
On 16-11-16 18:11:13, David Howells wrote:
> Allow keys to be added to the system secondary certificates keyring during
> kernel initialisation in an unrestricted fashion. Such keys are implicitly
> trusted and don't have their trust chains checked on link.
Well, I for one do not explicitly tru
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
On 16-08-10 14:40:13, David Laight wrote:
> From: Linuxppc-dev
> [mailto:linuxppc-dev-bounces+david.laight=aculab@lists.ozlabs.org] On
> Behalf Of
> > > > So given what you have above, you'd use something like:
> > > >
> > > > struct ima_kexec_hdr {
> > > > u16 version;
> > > >
On 16-08-10 08:54:36, Mimi Zohar wrote:
> On Wed, 2016-08-10 at 19:52 +1000, Michael Ellerman wrote:
> > Thiago Jung Bauermann writes:
> >
> > > Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman:
> > >> Thiago Jung Bauermann writes:
> > >> > Am Dienstag, 09 August 2016, 09:01:13 sch
On 16-08-05 09:34:38, Mimi Zohar wrote:
> Hi Petko,
>
> Thank you for review!
>
> On Fri, 2016-08-05 at 11:44 +0300, Petko Manolov wrote:
> > On 16-08-04 08:24:29, Mimi Zohar wrote:
> > > The TPM PCRs are only reset on a hard reboot. In order to validate a
> &g
On 16-08-04 08:24:29, Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and restored on boot. This patch
> restores the measurement list.
>
> Ch
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
On 16-03-08 16:07:00, David Howells wrote:
> Petko Manolov wrote:
>
> > > How about I change it to a choice-type item, with the following options:
> > >
> > > (1) No addition.
> > >
> > > (2) Addition restricted by built-in keyring.
> &g
On 16-03-08 14:44:24, David Howells wrote:
> Petko Manolov wrote:
>
> > I would suggest leaving (1) and (3).
>
> Do you mean dropping option (2) and leaving (1) and (3)? Or do you mean
> dropping options (1) and (3)?
Dropping option (2) and leaving (1) and (3).
(2) is s
On 16-03-08 13:13:59, David Howells wrote:
> Mimi Zohar wrote:
>
> > but we're left with a lot of references to "system_trusted" (eg.
> > restrict_link_to_system_trusted, depends on SYSTEM_TRUSTED_KEYRING
>
> How about I pluralise it to SYSTEM_TRUSTED_KEYRINGS? The fact that one is
> called bui
On 16-03-08 13:08:36, David Howells wrote:
> Mimi Zohar wrote:
>
> > Only certificates signed by a key on the system keyring were added to
> > the IMA keyring, unless IMA_MOK_KEYRING was configured. Then, the
> > certificate could be signed by a either a key on the system or ima_mok
> > keyrings
I assume this is intended for 4.6 or later, correct?
Petko
On 16-01-19 11:30:26, David Howells wrote:
>
> Here's a set of patches that changes how certificates/keys are determined
> to be trusted. That's currently a two-step process:
>
> (1) Up until recently, when an X.509
On 16-01-06 13:21:27, David Howells wrote:
> Mimi Zohar wrote:
>
> > The x509_validate_trust() was originally added for IMA to ensure, on a
> > secure boot system, a certificate chain of trust rooted in hardware. The
> > IMA
> > MOK keyring extends this certificate chain of trust to the runnin
On 16-01-05 16:40:31, David Howells wrote:
> Mimi Zohar wrote:
>
> > You're missing Petko's patch:
> > 41c89b6 IMA: create machine owner and blacklist keyrings
>
> It should also be cc'd to the keyrings mailing list.
Right.
If i am not terribly mistaken there's no way to revoke a certificate t
On 16-01-01 04:34:16, Al Viro wrote:
> On Thu, Dec 31, 2015 at 12:45:35PM +0200, Petko Manolov wrote:
>
> > I introduced the write mutex when ima_write_policy() stopped being
> > serialized by
> > other means. Come to think about it the semaphore could be
On 15-12-31 04:30:19, Al Viro wrote:
> On Thu, Dec 31, 2015 at 03:24:53PM +1100, Stephen Rothwell wrote:
> > Hi James,
> >
> > Today's linux-next merge of the security tree got a conflict in:
> >
> > security/integrity/ima/ima_fs.c
> >
> > between commit:
> >
> > 3bc8f29b149e ("new helper:
On 15-12-22 16:50:01, Sasha Levin wrote:
> On 12/22/2015 04:40 PM, Petko Manolov wrote:
> >> Thanks, Sasha. By the time ima_update_policy() is called
> >> >ima_release_policy() has already output the policy update status
> >> >message. I guess an empty polic
On December 22, 2015 9:56:28 PM GMT+02:00, Mimi Zohar
wrote:
>On Tue, 2015-12-22 at 08:51 -0500, Sasha Levin wrote:
>> Commit "IMA: policy can now be updated multiple times" assumed that
>the
>> policy would be updated at least once.
>>
>> If there are zero updates, the temporary list head objec
On 15-10-23 14:43:53, Mimi Zohar wrote:
> On Fri, 2015-10-23 at 16:05 +0300, Petko Manolov wrote:
> > On 15-10-22 21:49:25, Dmitry Kasatkin wrote:
>
> > > diff --git a/security/integrity/ima/Kconfig
> > > b/security/integrity/ima/Kconfig
> > > index df303
On 15-10-22 21:49:25, Dmitry Kasatkin wrote:
> Require all keys added to the EVM keyring be signed by an
> existing trusted key on the system trusted keyring.
>
> This patch also switches IMA to use integrity_init_keyring().
>
> Changes in v3:
> * Added 'init_keyring' config based variable to ski
On 15-10-21 13:02:48, Mimi Zohar wrote:
> On Wed, 2015-10-21 at 16:13 +0100, David Howells wrote:
> > Here's a set of patches that changes how keys are determined to be trusted
> > - currently, that's a case of whether a key has KEY_FLAG_TRUSTED set upon
> > it. A keyring can then have a flag set
On May 26, 2015 7:15:38 PM GMT+03:00, David Howells wrote:
>Hi Michal,
>
>Could you have a look at the patch at the end of my branch:
>
>
> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7
>
>It changes things from picking up arbitrary *.x509 files dr
On 15-05-26 18:08:13, One Thousand Gnomes wrote:
> On Thu, 21 May 2015 18:53:19 +0300
> Petko Manolov wrote:
>
> > It is device's job to verify firmware's correctness. It is user's job to
> > verify vendor's identity. Two different things, not relate
On 15-05-22 08:28:17, Mimi Zohar wrote:
> On Fri, 2015-05-22 at 08:48 +0100, David Howells wrote:
> > Luis R. Rodriguez wrote:
> >
> > > > This is similar to what i am doing right now - create CA hierarchy so
> > > > we can
> > > > have something like:
> > > >
> > > >
On 15-05-21 09:55:42, Andy Lutomirski wrote:
>
> I read plenty of the code. I said "data" not "file" for a reason.
> I'll quote some code:
>
> int ima_appraise_measurement(int func, struct integrity_iint_cache *iint,
> struct file *file, const unsigned char *filename
On 15-05-21 10:02:36, gre...@linuxfoundation.org wrote:
> On Thu, May 21, 2015 at 04:03:02PM +, Woodhouse, David wrote:
> >
> > In a lot of cases we have loadable firmware precisely to allow us to
> > reduce the cost of the hardware. Adding cryptographic capability in the
> > 'load firmware' s
On 15-05-21 09:48:10, Andy Lutomirski wrote:
> On Thu, May 21, 2015 at 9:43 AM, Petko Manolov wrote:
> > On 15-05-21 16:51:49, David Howells wrote:
> >>
> >> I do have patches to parse PGP key data and add the public keys found
> >> therein
> >>
On 15-05-21 09:39:50, Andy Lutomirski wrote:
>
> It's also a performance cost because the average user of this signature stuff
> doesn't actually want IMA, and IMA is checking the wrong think anyway.
> IMA/EVM tells us "this file validly belongs in /lib/modules/whatever
> according
> to whome
On 15-05-21 16:51:49, David Howells wrote:
>
> I do have patches to parse PGP key data and add the public keys found therein
> onto the kernel keyring, but that would mean adding an extra key data parser.
PGP is widely used so i would gladly have one more parser in the kernel.
> You could probab
On 15-05-21 08:45:08, Greg Kroah-Hartman wrote:
> On Thu, May 21, 2015 at 09:05:21AM -0400, Mimi Zohar wrote:
> >
> > Signatures don't provide any guarantees as to code quality or
> > correctness. They do provide file integrity and provenance. In
> > addition to the license and a Signed-off-by
On 15-05-20 23:14:53, Greg Kroah-Hartman wrote:
>
> Ok, but how do we know "where"? Who is going to start signing and attesting
> to the validity of all of the firmware images in the linux-firmware tree
> suddenly? Why is it the kernel's job to attest this "where"? Shouldn't your
> distro/ma
On 15-05-20 21:41:04, Greg Kroah-Hartman wrote:
> On Wed, May 20, 2015 at 07:46:13PM +0300, Petko Manolov wrote:
> > On 15-05-20 17:24:46, One Thousand Gnomes wrote:
> > >
> > > More to the point why do you want to sign firmware files ? Leaving aside
> > &g
On 15-05-20 09:41:21, Andy Lutomirski wrote:
> On Wed, May 20, 2015 at 9:21 AM, Petko Manolov wrote:
> > On 15-05-20 08:56:21, Andy Lutomirski wrote:
> >>
> >> Would it make more sense to permit X.509 chains to be loaded into the
> >> keyring
> >> i
On 15-05-20 17:24:46, One Thousand Gnomes wrote:
>
> More to the point why do you want to sign firmware files ? Leaving aside the
> fact that someone will produce a device with GPLv3 firmware just to p*ss you
> off there's the rather more relevant fact that firmware for devices on a so
> called
On 15-05-20 08:56:21, Andy Lutomirski wrote:
>
> Would it make more sense to permit X.509 chains to be loaded into the keyring
> instead if we actually need that feature? IOW, let userspace (or early
> initramfs stuff) extend our keyring trust to intermediate certs that validly
> chain to alre
On 15-05-19 17:22:59, Luis R. Rodriguez wrote:
>
> I have a series of reasons find IMA unsuitable for the current goals at hand:
>
> 1) IMA is a pretty big kitchen sink, we want this to work well for
> even embedded systems, or architectures that do not have or require
> TPMs
No, it isn't. I'v
On 15-05-19 19:10:07, Andy Lutomirski wrote:
> On Tue, May 19, 2015 at 7:05 PM, Mimi Zohar wrote:
> >
> > Perhaps you're referring to EVM?
>
> I don't know. I also couldn't figure out what IMA was and what EVM was.
Try reading this:
http://sourceforge.net/p/linux-ima/wiki/Home/
A little outda
On 15-05-19 17:15:12, David Woodhouse wrote:
> On Tue, 2015-05-19 at 18:50 +0300, Petko Manolov wrote:
> > On 15-05-19 15:45:58, David Woodhouse wrote:
> > > We don't want this in the Kconfig since it might then get exposed in
> > > /proc/config.gz. So make it a p
On 15-05-19 15:45:58, David Woodhouse wrote:
> We don't want this in the Kconfig since it might then get exposed in
> /proc/config.gz. So make it a parameter to Kbuild instead. This also
> means we don't have to jump through hoops to strip quotes from it, as
> we would if it was a config option.
I
On 15-05-19 11:37:49, Mimi Zohar wrote:
> On Tue, 2015-05-19 at 07:36 -0700, Andy Lutomirski wrote:
> >
> > What integrity stuff? IIRC dm-verity doesn't use asymmetric crypto at
> > all. IMA probably does, though.
>
> IMA can appraise file integrity based on either hashes or signatures.
> The d
On 15-05-19 11:55:32, Theodore Ts'o wrote:
>
> So I'm really curious --- are there significant numbers of people
> doing kernel builds, besides distro kernel engineers, who would use
> module signing? If so, them sure, let's spend time optimizing so that
> it's really easy for those folks. If not
On 14-11-18 18:29:59, Sudip Mukherjee wrote:
> we were just returning the initial value of res, instead now
> we are returning the value directly.
Looks OK, but could you please fix the wording of the commit message to
something like:
Remove unused variable.
This is a tiny patch and the
> 1 file changed, 52 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 6e87e57..1e1c408 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -21,27 +21,27 @@
> #define DRIVE
From: Petko Manolov
Date: Fri, 15 Nov 2013 11:51:54 +0200
Subject: [PATCH] Update Pegasus and RTL8150 repositories;
Update Pegasus and RTL8150 driver repositories;
The diff is against latest 'net' repository;
Signed-off-by: Petko Manolov
---
MAINTAINERS | 8
1 file
On Mon, 20 May 2013, Ben Hutchings wrote:
> [...]
> > @@ -771,12 +770,12 @@ static void rtl8150_disconnect(struct usb_interface
> > *intf)
> > }
> >
> > static struct usb_driver rtl8150_driver = {
> > - .name = driver_name,
> > - .probe = rtl8150_probe,
> > - .disconn
On Mon, 20 May 2013, Ben Hutchings wrote:
> Now how is this driver going to compile, when rtl8150.h is only added by
> the next patch?!
I got carried away by the desire to make each patch smaller and to the
point. Sacrificing build-ability of the tree, however, does not justify
it. My bad.
>
From: Petko Manolov
This patch fixes a potential race with concurrently running asynchronous
write requests. The values for device's RX control register are now
stored in dynamically allocated buffers so each URB submission has it's
own copy. Doing it the old way is data clobbe
On Mon, 20 May 2013, David Miller wrote:
> From: Petko Manolov
> Date: Mon, 20 May 2013 10:18:17 +0300 (EEST)
>
> > On Mon, 20 May 2013, David Miller wrote:
> >
> >> From: Petko Manolov
> >> Date: Mon, 20 May 2013 10:09:00 +0300 (EEST)
> >>
On Mon, 20 May 2013, David Miller wrote:
> From: Petko Manolov
> Date: Mon, 20 May 2013 10:09:00 +0300 (EEST)
>
> > What about the .c/.h split?
>
> I have no strong opinion either way.
OK, so i'll prepare new patch series that coalesce my original patch #1
and
On Mon, 20 May 2013, David Miller wrote:
> From: Petko Manolov
> Date: Mon, 20 May 2013 09:58:39 +0300 (EEST)
>
> > So first apply patch #1 and then patch #2.
>
> Then nobody can properly GIT bisect through your patch series.
>
> The tree must work and build prop
On Sun, 19 May 2013, Francois Romieu wrote:
> Which one ?
> - share it through the kernel or with userspace
> - personal choice .c split
It is obviously not the former. I think that in general constant and
other definitions (in their majority) should be in a header file. I
definitely like th
On Sat, 18 May 2013, Francois Romieu wrote:
> Petko Manolov :
> [...]
> > static int set_registers(rtl8150_t * dev, u16 indx, u16 size, void *data)
> > {
> > - return usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
> > -
On Sat, 18 May 2013, Francois Romieu wrote:
> Petko Manolov :
> [...]
> > diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> > index 7d1897b..fd4bc2a 100644
> > --- a/drivers/net/usb/rtl8150.c
> > +++ b/drivers/net/usb/rtl8150.c
> [...]
> &
On Sat, 18 May 2013, Francois Romieu wrote:
> Petko Manolov :
> > From: Petko Manolov
> >
> > Moving constant and structure definitions out of rtl8150.c;
>
> What's the point ?
The general logic of having .h files applies.
> [...]
> >
On Sat, 18 May 2013, Francois Romieu wrote:
> Petko Manolov :
> [...]
> > @@ -681,16 +681,15 @@ static int rtl8150_ioctl(struct net_device *netdev,
> > struct ifreq *rq, int cmd)
> > }
> >
> > static const struct net_device_ops rtl8
On Sat, 18 May 2013, Francois Romieu wrote:
> Petko Manolov :
> [...]
> > This patch series adds rtl8150.h, which contains structure and constant
> > definitons formerly found in rtl8150.c, removes socket buffer
> > pre-allocated pool and uses dynamically
From: Petko Manolov
Moving constant and structure definitions out of rtl8150.c;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 121 +--
1 file changed, 2 insertions(+), 119 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb
From: Petko Manolov
adding rtl8150.h;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.h | 131 +++
1 file changed, 131 insertions(+)
diff --git a/drivers/net/usb/rtl8150.h b/drivers/net/usb/rtl8150.h
new file mode 100644
index 000..cfb1e74
From: Petko Manolov
copyright, email address and styling update;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 69 +--
1 file changed, 34 insertions(+), 35 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index
From: Petko Manolov
removing socket buffer pre-allocation pool;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 60 +++
drivers/net/usb/rtl8150.h |3 --
2 files changed, 5 insertions(+), 58 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c
From: Petko Manolov
[get|set]_registers() will now display a message in case of error condition
and if DEBUG is enabled. All resources required for asynchronous control URB
submission are being dynamically (de)allocated.
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 129
From: Petko Manolov
This patch series adds rtl8150.h, which contains structure and constant
definitons formerly found in rtl8150.c, removes socket buffer
pre-allocated pool and uses dynamically allocated memory for the
asynchronous URB requests, thus avoids clobbering the previously scheduled
From: Petko Manolov
Moving constant and structure definitions out of rtl8150.c;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 121 +--
1 file changed, 2 insertions(+), 119 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb
From: Petko Manolov
copyright, email address and styling update;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 69 +--
1 file changed, 34 insertions(+), 35 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index
From: Petko Manolov
[get|set]_registers() will now display a message in case of error condition
and if DEBUG is enabled. All resources required for asynchronous control URB
submission are being dynamically (de)allocated.
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 129
From: Petko Manolov
removing socket buffer pre-allocation pool;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.c | 60 +++
drivers/net/usb/rtl8150.h |3 --
2 files changed, 5 insertions(+), 58 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c
From: Petko Manolov
This patch series adds rtl8150.h, which contains structure and constant
definitons formerly found in rtl8150.c, removes socket buffer
pre-allocated pool and uses dynamically allocated memory for the
asynchronous URB requests, thus avoids clobbering the previously scheduled
From: Petko Manolov
adding rtl8150.h;
Signed-off-by: Petko Manolov
---
drivers/net/usb/rtl8150.h | 131 +++
1 file changed, 131 insertions(+)
diff --git a/drivers/net/usb/rtl8150.h b/drivers/net/usb/rtl8150.h
new file mode 100644
index 000..cfb1e74
On Fri, 26 Apr 2013, Petko Manolov wrote:
> From: Petko Manolov
>
> This series of patches is fixing a bug related to multiple control URB
> submissions (noted by Sarah Sharp), optimizes read and write_mii_word
> routines and removes socket buffer pool used in the receive pa
From: Petko Manolov
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic it didn't always work. As a result of this change
[get|set]_registers() are now much simpler. Async write is also l
From: Petko Manolov
Duplicated code in routines reading and writing MII registers is now
packed in __mii_op().
Signed-off-by: Petko Manolov
---
Diff made against latest net-next, not my git repository;
drivers/net/usb/pegasus.c | 85 +++
1 file changed, 35
From: Petko Manolov
The socket buffer pool for the receive path is now gone. It's existence
didn't make much difference (performance-wise) and the code is better off
without the spinlocks protecting it.
Signed-off-by: Petko Manolov
---
Diff made against latest net-next,
On Fri, 26 Apr 2013, David Miller wrote:
>
> I explicitly asked for an initial "[PATCH 0/N] " posting, preceeding
> the patches, giving a high level description of the changes made in
> this series.
I am sorry, this [patch 0/n] approach is new to me. I just wrote up a
high level description of
From: Petko Manolov
This series of patches is fixing a bug related to multiple control URB
submissions (noted by Sarah Sharp), optimizes read and write_mii_word
routines and removes socket buffer pool used in the receive path.
Signed-off-by: Petko Manolov
--
To unsubscribe from this list
From: Petko Manolov
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic it didn't always work. As a result of this change
[get|set]_registers() are now much simpler. Async write is also l
From: Petko Manolov
The socket buffer pool for the receive path is now gone. It's existence
didn't make much difference (performance-wise) and the code is better off
without the spinlocks protecting it.
Signed-off-by: Petko Manolov
---
pegasu
From: Petko Manolov
Duplicated code in routines reading and writing MII registers is now
packed in __mii_op().
Signed-off-by: Petko Manolov
---
pegasus.c | 85 +--
1 file changed, 35 insertions(+), 50 deletions(-)
diff --git a/pegasus.c b
From: Petko Manolov
(For inclusion in 3.10, diff against latest net-next.)
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic (as Sarah Sharp spotted) it didn't always work. As a result of
On Fri, 12 Apr 2013, David Miller wrote:
When submitting a new version of a patch, you must list what changed
from the previous version after the "---" delimiter rather than having
people try and guess.
Got it. However, i've already spammed you, Sarah and two major mailing
lists so i assume
From: Petko Manolov
(For inclusion in 3.10, diff against latest net-next.)
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic (as Sarah Sharp spotted) it didn't always work. As a result of
On Thu, 11 Apr 2013, Dan Williams wrote:
> On Thu, 2013-04-11 at 10:09 +0300, Petko Manolov wrote:
> > From: Petko Manolov
> >
> > (For inclusion in 3.10, diff against latest net-next.)
>
> Your mail client replaced tabs with spaces. Make sure when adding the
>
From: Petko Manolov
(For inclusion in 3.10, diff against latest net-next.)
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic (as Sarah Sharp spotted) it didn't always work. As a resu
From: Petko Manolov
Pegasus driver used single callback for sync and async control URBs.
Special flags were employed to distinguish between both, but due to flawed
logic it didn't always work.
Now [get|set]_registers() are much simpler. Async write is also leaner
and does not use s
1 - 100 of 138 matches
Mail list logo
