On Wed, 4 Mar 2015 14:36:10 +0100
Rafał Miłecki zaj...@gmail.com wrote:
Any other opinions?
I think this is the only way to go.
In ssb we always had optional pcicore driver, as far as I remember,
so we should have the same in bcma, too.
The old WRT54G kernel used to compile just fine with SSB
On Fri, 2 Jan 2015 12:19:12 +0100
Rafał Miłecki wrote:
> On 2 January 2015 at 10:27, Michael Büsch wrote:
> > On Fri, 2 Jan 2015 02:34:01 -0500
> > Nicholas Krause wrote:
> >
> >> This adds proper locking for the function, b43_op_beacon_set_tim in main.c
On Fri, 2 Jan 2015 02:34:01 -0500
Nicholas Krause wrote:
> This adds proper locking for the function, b43_op_beacon_set_tim in main.c by
> using the mutex lock
> in the structure pointer wl, as embedded into this pointer as a mutex in
> order to protect against
> multiple access to the
On Fri, 2 Jan 2015 02:34:01 -0500
Nicholas Krause xerofo...@gmail.com wrote:
This adds proper locking for the function, b43_op_beacon_set_tim in main.c by
using the mutex lock
in the structure pointer wl, as embedded into this pointer as a mutex in
order to protect against
multiple access
On Fri, 2 Jan 2015 12:19:12 +0100
Rafał Miłecki zaj...@gmail.com wrote:
On 2 January 2015 at 10:27, Michael Büsch m...@bues.ch wrote:
On Fri, 2 Jan 2015 02:34:01 -0500
Nicholas Krause xerofo...@gmail.com wrote:
This adds proper locking for the function, b43_op_beacon_set_tim in main.c
On Wed, 3 Dec 2014 11:14:52 -0500
"John W. Linville" wrote:
> On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote:
> > On Tue, 02 Dec 2014 16:23:49 -0600
> > Larry Finger wrote:
> >
> > > On 12/02/2014 02:12 PM, Michael Büsch wrote:
&
On Tue, 02 Dec 2014 16:23:49 -0600
Larry Finger wrote:
> On 12/02/2014 02:12 PM, Michael Büsch wrote:
> > On Tue, 2 Dec 2014 23:01:29 +0300
> > Andrey Skvortsov wrote:
> >
> >> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
> >>> On Mo
On Tue, 02 Dec 2014 16:23:49 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
On 12/02/2014 02:12 PM, Michael Büsch wrote:
On Tue, 2 Dec 2014 23:01:29 +0300
Andrey Skvortsov andrej.skvort...@gmail.com wrote:
On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
On Mon, 1
On Wed, 3 Dec 2014 11:14:52 -0500
John W. Linville linvi...@tuxdriver.com wrote:
On Wed, Dec 03, 2014 at 04:18:55PM +0100, Michael Büsch wrote:
On Tue, 02 Dec 2014 16:23:49 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
On 12/02/2014 02:12 PM, Michael Büsch wrote:
On Tue, 2
On Tue, 2 Dec 2014 23:01:29 +0300
Andrey Skvortsov wrote:
> On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
> > On Mon, 1 Dec 2014 23:46:38 +0300
> > Andrey Skvortsov wrote:
> >
> > > Wake On Lan was not working on laptop DELL Vostro 1500.
>
On Tue, 2 Dec 2014 23:01:29 +0300
Andrey Skvortsov andrej.skvort...@gmail.com wrote:
On Mon, Dec 01, 2014 at 10:10:23PM +0100, Michael Büsch wrote:
On Mon, 1 Dec 2014 23:46:38 +0300
Andrey Skvortsov andrej.skvort...@gmail.com wrote:
Wake On Lan was not working on laptop DELL Vostro
On Mon, 1 Dec 2014 23:46:38 +0300
Andrey Skvortsov wrote:
> Wake On Lan was not working on laptop DELL Vostro 1500.
> If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
> But the laptop could not be woken up with the Magic Packet. The reason for
> that was that PCIE was
On Mon, 1 Dec 2014 23:46:38 +0300
Andrey Skvortsov andrej.skvort...@gmail.com wrote:
Wake On Lan was not working on laptop DELL Vostro 1500.
If WOL was turned on, BCM4401 was powered up in suspend mode. LEDs blinked.
But the laptop could not be woken up with the Magic Packet. The reason for
On Fri, 28 Nov 2014 22:32:30 -0500
nick wrote:
> I don't have hardware for this driver on me, so I didn't test it. However
> this seems to
> be correct from my reading of the code around this function and other locking
> related
> to this driver.
From the current docs:
> * @set_tim: Set
On Fri, 28 Nov 2014 22:32:30 -0500
nick xerofo...@gmail.com wrote:
I don't have hardware for this driver on me, so I didn't test it. However
this seems to
be correct from my reading of the code around this function and other locking
related
to this driver.
From the current docs:
*
On Fri, 28 Nov 2014 23:40:46 +0100
Rafał Miłecki wrote:
> > @@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw
> > *hw,
> > {
> > struct b43_wl *wl = hw_to_b43_wl(hw);
> >
> > - /* FIXME: add locking */
> > + mutex_lock(>mutex);
> >
On Fri, 28 Nov 2014 23:40:46 +0100
Rafał Miłecki zaj...@gmail.com wrote:
@@ -5094,8 +5094,9 @@ static int b43_op_beacon_set_tim(struct ieee80211_hw
*hw,
{
struct b43_wl *wl = hw_to_b43_wl(hw);
- /* FIXME: add locking */
+ mutex_lock(wl-mutex);
On Tue, 28 Oct 2014 22:03:02 +0530
Pramod Gurav wrote:
> Michael had suggested to do away with this function if not being used.
> Good to go?
>
> Michale can you provide acked-by?
Yes, this looks good.
Acked-by: Michael Büsch
> On Wed, Oct 1, 2014 at 10:58 PM, Pramod
On Tue, 28 Oct 2014 22:03:02 +0530
Pramod Gurav pramod.gurav@gmail.com wrote:
Michael had suggested to do away with this function if not being used.
Good to go?
Michale can you provide acked-by?
Yes, this looks good.
Acked-by: Michael Büsch m...@bues.ch
On Wed, Oct 1, 2014 at 10:58 PM
On Sun, 26 Oct 2014 22:25:04 -0700
Joe Perches wrote:
> Precedence of & and >> is not the same and is not left to right.
> shift has higher precedence and should be done after the mask.
>
> Add parentheses around the mask.
>
> Signed-off-by: Joe Perches
Good
.
Reviewed-by: Michael Büsch m...@bues.ch
---
drivers/ssb/driver_chipcommon_pmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ssb/driver_chipcommon_pmu.c
b/drivers/ssb/driver_chipcommon_pmu.c
index 1173a09..bc71583 100644
--- a/drivers/ssb
On Wed, 01 Oct 2014 13:09:31 +0530
Pramod Gurav wrote:
> On Wednesday 01 October 2014 12:59 PM, Paul Bolle wrote:
> > On Wed, 2014-10-01 at 12:36 +0530, Pramod Gurav wrote:
> >> This change fixes below sparse error:
> >>
> >> drivers/ssb/main.c:94:16: warning: symbol 'ssb_sdio_func_to_bus'
> >>
On Wed, 01 Oct 2014 13:09:31 +0530
Pramod Gurav pramod.gu...@smartplayin.com wrote:
On Wednesday 01 October 2014 12:59 PM, Paul Bolle wrote:
On Wed, 2014-10-01 at 12:36 +0530, Pramod Gurav wrote:
This change fixes below sparse error:
drivers/ssb/main.c:94:16: warning: symbol
On Tue, 16 Sep 2014 08:27:40 +0800
Amos Kong wrote:
> Set timeout to 10:
> non-smp guest with quick backend (1.2M/s) -> about 490K/s)
That sounds like an awful lot. This is a 60% loss in throughput.
I don't think we can live with that.
--
Michael
signature.asc
Description: PGP signature
On Tue, 16 Sep 2014 08:27:40 +0800
Amos Kong ak...@redhat.com wrote:
Set timeout to 10:
non-smp guest with quick backend (1.2M/s) - about 490K/s)
That sounds like an awful lot. This is a 60% loss in throughput.
I don't think we can live with that.
--
Michael
signature.asc
Description:
On Tue, 16 Sep 2014 00:02:29 +0800
Amos Kong wrote:
> This patch increases the schedule timeout to 10 jiffies, it's more
> appropriate, then other takes can easy to hold the mutex lock.
>
> Signed-off-by: Amos Kong
> ---
> drivers/char/hw_random/core.c | 2 +-
> 1 file changed, 1
On Tue, 16 Sep 2014 00:02:27 +0800
Amos Kong wrote:
> It doesn't save too much cpu time as expected, just a cleanup.
>
> Signed-off-by: Amos Kong
> ---
> drivers/char/hw_random/core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/core.c
On Tue, 16 Sep 2014 00:02:29 +0800
Amos Kong ak...@redhat.com wrote:
This patch increases the schedule timeout to 10 jiffies, it's more
appropriate, then other takes can easy to hold the mutex lock.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 2 +-
1
On Tue, 16 Sep 2014 00:02:27 +0800
Amos Kong ak...@redhat.com wrote:
It doesn't save too much cpu time as expected, just a cleanup.
Signed-off-by: Amos Kong ak...@redhat.com
---
drivers/char/hw_random/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
On Wed, 14 May 2014 23:43:36 +0200
abdoulaye berthe wrote:
> this fixes a compilation warning by checking
> the retun value of gpiochip_remove()
Really, I would rather change the gpiochip_remove return type to void.
What is the point of printing a useless error message in case
of a failure
On Wed, 14 May 2014 23:43:36 +0200
abdoulaye berthe berthe...@gmail.com wrote:
this fixes a compilation warning by checking
the retun value of gpiochip_remove()
Really, I would rather change the gpiochip_remove return type to void.
What is the point of printing a useless error message in
In order to improve the media coverage of important developer
conference events, extend the Linux event subsystem by corresponding
event type numbers.
Instead of referring to events by cryptic acronyms that nobody
knows the real meaning of, use even shorter acronyms defined to
hexadecimal numbers
In order to improve the media coverage of important developer
conference events, extend the Linux event subsystem by corresponding
event type numbers.
Instead of referring to events by cryptic acronyms that nobody
knows the real meaning of, use even shorter acronyms defined to
hexadecimal numbers
On Sun, 24 Feb 2013 11:31:47 -0600
Larry Finger wrote:
> With the current wireless-testing tree, unloading b43 produces the lockdep
> log
> splat copied below. My understanding of locking is deficient, and I would
> like
> to learn. Any help on understanding this problem is appreciated.
A
On Sun, 24 Feb 2013 11:31:47 -0600
Larry Finger larry.fin...@lwfinger.net wrote:
With the current wireless-testing tree, unloading b43 produces the lockdep
log
splat copied below. My understanding of locking is deficient, and I would
like
to learn. Any help on understanding this problem
On Sun, 7 Oct 2012 18:50:31 +0200 (CEST)
Julia Lawall wrote:
> >> @@ -97,10 +96,8 @@ static int fc0011_readreg(struct fc0011_priv *priv, u8
> >> reg, u8 *val)
> >> {
> >>u8 dummy;
> >>struct i2c_msg msg[2] = {
> >> - { .addr = priv->addr,
> >> -.flags = 0, .buf = ,
On Sun, 7 Oct 2012 18:50:31 +0200 (CEST)
Julia Lawall julia.law...@lip6.fr wrote:
@@ -97,10 +96,8 @@ static int fc0011_readreg(struct fc0011_priv *priv, u8
reg, u8 *val)
{
u8 dummy;
struct i2c_msg msg[2] = {
- { .addr = priv-addr,
-.flags = 0, .buf =
101 - 137 of 137 matches
Mail list logo
