On 4/17/21 3:24 PM, Gustavo A. R. Silva wrote:
>
>
> On 4/17/21 13:29, Jes Sorensen wrote:
>> On 3/10/21 3:59 PM, Kees Cook wrote:
>>> On Wed, Mar 10, 2021 at 02:51:24PM -0500, Jes Sorensen wrote:
>>>> On 3/10/21 2:45 PM, Kees Cook wrote:
>>>>
On 4/17/21 8:09 PM, Joe Perches wrote:
> On Sat, 2021-04-17 at 14:30 -0400, Jes Sorensen wrote:
>> On 4/17/21 1:52 PM, Kalle Valo wrote:
>>> "Gustavo A. R. Silva" wrote:
>>>
>>>> In preparation to enable -Wimplicit-fallthrough for Clang, fix
&g
On 4/17/21 1:52 PM, Kalle Valo wrote:
> "Gustavo A. R. Silva" wrote:
>
>> In preparation to enable -Wimplicit-fallthrough for Clang, fix
>> multiple warnings by replacing /* fall through */ comments with
>> the new pseudo-keyword macro fallthrough; instead of letting the
>> code fall through to t
On 3/10/21 3:59 PM, Kees Cook wrote:
> On Wed, Mar 10, 2021 at 02:51:24PM -0500, Jes Sorensen wrote:
>> On 3/10/21 2:45 PM, Kees Cook wrote:
>>> On Wed, Mar 10, 2021 at 02:31:57PM -0500, Jes Sorensen wrote:
>>>> On 3/10/21 2:14 PM, Kees Cook wrote:
>>&g
On 3/10/21 2:45 PM, Kees Cook wrote:
> On Wed, Mar 10, 2021 at 02:31:57PM -0500, Jes Sorensen wrote:
>> On 3/10/21 2:14 PM, Kees Cook wrote:
>>> Hm, this conversation looks like a miscommunication, mainly? I see
>>> Gustavo, as requested by many others[1], replacing t
On 3/10/21 2:14 PM, Kees Cook wrote:
> On Fri, Mar 05, 2021 at 03:40:33PM +0200, Kalle Valo wrote:
>> "Gustavo A. R. Silva" writes:
>>
>>> In preparation to enable -Wimplicit-fallthrough for Clang, fix
>>> multiple warnings by replacing /* fall through */ comments with
>>> the new pseudo-keyword m
On 11/20/20 1:38 PM, Gustavo A. R. Silva wrote:
> In preparation to enable -Wimplicit-fallthrough for Clang, fix
> multiple warnings by replacing /* fall through */ comments with
> the new pseudo-keyword macro fallthrough; instead of letting the
> code fall through to the next case.
>
> Notice tha
ou can, and
>>> let's see if anyone notices...
>>
>> That's what I would suggest as well.
>>
>> These drivers for ancient hardware are tricky. Even if there doesn't
>> seem to be any users on the driver sometimes people pop up reporting
>> t
ch of tdma settings
- Reformat some lines to meet kernel coding style
v3:
- Add comment for rtl8723bu_set_coex_with_type()
Looks good to me!
Signed-off-by: Jes Sorensen
Jes
On 6/25/19 2:00 PM, Saeed Mahameed wrote:
> On Tue, 2019-06-25 at 11:27 -0400, Jes Sorensen wrote:
>> From: Jes Sorensen
>>
>> The previous patch broke the build with a static declaration for
>> a public function.
>>
>> Fixes: 8f0916c6dc5c (ne
On 6/25/19 1:54 PM, Saeed Mahameed wrote:
> On Tue, 2019-06-25 at 11:27 -0400, Jes Sorensen wrote:
>> From: Jes Sorensen
>>
>> This fixes an obvious build error that could have been caught by
>> simply building the code before pushing out the patch.
>>
>
&g
From: Jes Sorensen
The previous patch broke the build with a static declaration for
a public function.
Fixes: 8f0916c6dc5c (net/mlx5e: Fix ethtool rxfh commands when
CONFIG_MLX5_EN_RXNFC is disabled)
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 3
From: Jes Sorensen
This fixes an obvious build error that could have been caught by
simply building the code before pushing out the patch.
Cheers,
Jes
Jes Sorensen (1):
mlx5: Fix build when CONFIG_MLX5_EN_RXNFC is disabled
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 3 ++-
1
On 05/18/2018 06:09 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in printk message text
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/hippi/rrunner.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/hippi/rrunner.
rdev-devel/2018-January/115390.html
>
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Jes Sorensen
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> b/drivers/net/wireless/realtek/rtl8xxxu/r
3acafbf0ecff4deb3e3cb554b34f0d0664.
> Note: kept mlx5_get_vector_affinity in include/linux/mlx5/driver.h since
> it is used in mlx5_ib driver.
>
> Fixes: a435393acafb ("mlx5: move affinity hints assignments to generic code")
> Cc: Sagi Grimberg
> Cc: Thomas Gleixner
&
On 11/22/2017 04:51 AM, Mylene JOSSERAND wrote:
> Hello Jes Sorensen,
>
> I am currently testing a LM811 Wifi/BT USB dongle [1] on a Sinlinx
> SinA33 Allwinner SoC board [2]. I saw that I should use the realtek
> driver RTL8723BU for this USB dongle.
>
> Currently, I am only
On 11/08/2017 12:33 PM, Thomas Gleixner wrote:
> On Wed, 8 Nov 2017, Jes Sorensen wrote:
>> On 11/07/2017 10:07 AM, Thomas Gleixner wrote:
>>> Depending on the machine and the number of queues this might even result in
>>> completely losing the ability to suspend/hibe
On 11/07/2017 10:07 AM, Thomas Gleixner wrote:
> On Sun, 5 Nov 2017, Sagi Grimberg wrote:
>> I do agree that the user would lose better cpu online/offline behavior,
>> but it seems that users want to still have some control over the IRQ
>> affinity assignments even if they lose this functionality.
On 11/02/2017 12:14 PM, Sagi Grimberg wrote:
>
>> This wasn't to start a debate about which allocation method is the
>> perfect solution. I am perfectly happy with the new default, the part
>> that is broken is to take away the user's option to reassign the
>> affinity. That is a bug and it needs
On 11/02/2017 06:08 AM, Sagi Grimberg wrote:
>
I vaguely remember Nacking Sagi's patch as we knew it would break
mlx5e netdev affinity assumptions.
>> I remember that argument. Still the series found its way in.
>
> Of course it maid its way in, it was acked by three different
> maintai
On 11/01/2017 06:41 PM, Saeed Mahameed wrote:
> On Wed, Nov 1, 2017 at 11:20 AM, Jes Sorensen wrote:
>> On 11/01/2017 01:21 PM, Sagi Grimberg wrote:
>> I am all in favor of making the automatic setup better, but assuming an
>> automatic setup is always right seems proble
On 11/01/2017 01:21 PM, Sagi Grimberg wrote:
>> Hi,
>
> Hi Jes,
>
>> The below patch seems to have broken PCI IRQ affinity assignments for
>> mlx5.
>
> I wouldn't call it breaking IRQ affinity assignments. It just makes
> them automatic.
Well it explicitly breaks the option for an admin to assi
Hi,
The below patch seems to have broken PCI IRQ affinity assignments for mlx5.
Prior to this patch I could echo a value to /proc/irq//smp_affinity
and it would get assigned. With this patch applied I get -EIO
The actual affinity assignments seem to have changed too, but I assume
this is a resul
On 10/25/2017 06:51 AM, Kees Cook wrote:
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.
Cc: Jes Sorensen
Cc: linux-hi...@sunsite.dk
Cc: netdev
On 10/11/2017 04:41 AM, Kalle Valo wrote:
Jes Sorensen writes:
On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
While this isn't harmful, to me this looks like pointless
On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
While this isn't harmful, to me this looks like pointless patch churn
for zero gain and it's just ugly.
Jes
Cc: Jes So
On 06/13/2017 01:58 PM, Saeed Mahameed wrote:
On Mon, Jun 12, 2017 at 9:20 PM, Jes Sorensen wrote:
On 06/07/2017 07:42 PM, Saeed Mahameed wrote:
This patch gives the option to chose whether to compile the driver with or
without eswitch/eswitch_offloads(switchdev mode)/en_rep(VF representors
On 06/13/2017 01:49 PM, Saeed Mahameed wrote:
On Mon, Jun 12, 2017 at 8:52 PM, Jes Sorensen wrote:
On 06/07/2017 07:42 PM, Saeed Mahameed wrote:
Multi-Physical Function Switch (MPFs) is required for when multi-PF
configuration is enabled to allow passing user configured unicast MAC
addresses
On 06/07/2017 07:42 PM, Saeed Mahameed wrote:
This patch gives the option to chose whether to compile the driver with or
without eswitch/eswitch_offloads(switchdev mode)/en_rep(VF representors)
and en_tc offloads.
It also removes most of the above modules headers declarations and stubs
out the A
On 06/07/2017 07:42 PM, Saeed Mahameed wrote:
Multi-Physical Function Switch (MPFs) is required for when multi-PF
configuration is enabled to allow passing user configured unicast MAC
addresses to the requesting PF.
Before this patch eswitch.c used to manage the HW MPFS l2 table,
eswitch always
On 06/07/2017 12:06 AM, Saeed Mahameed wrote:
On Wed, Jun 7, 2017 at 12:46 AM, Jes Sorensen wrote:
Hey Jes,
It is not just about squashing patches, I am working on a series of
patches to allow compiling out eswitch/eswitch_offloads/en_rep.c/en_tc
altogether, it will come out cleaner as it
On 06/05/2017 05:53 PM, Saeed Mahameed wrote:
On Mon, Jun 5, 2017 at 11:51 PM, Jes Sorensen wrote:
On 06/03/2017 03:37 PM, Or Gerlitz wrote:
On Fri, Jun 2, 2017 at 11:22 PM, Jes Sorensen wrote:
On 05/28/2017 02:03 AM, Or Gerlitz wrote:
On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen
This provides the option for TC offload support to be disabled in the
driver.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 10 ++
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 ++-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 39
Hi,
Here is the follow-on patch which allows for TC support to be compiled
out.
It builds on top of my patch set from last week.
Jes
Jes Sorensen (1):
mlx5: Allow TC support to be disabled in the build
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 10 ++
drivers/net/ethernet
On 06/03/2017 03:37 PM, Or Gerlitz wrote:
On Fri, Jun 2, 2017 at 11:22 PM, Jes Sorensen wrote:
On 05/28/2017 02:03 AM, Or Gerlitz wrote:
On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen
wrote:
On 05/27/2017 05:02 PM, Or Gerlitz wrote:
On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen
wrote
On 05/28/2017 03:24 AM, Ilan Tayari wrote:
-Original Message-
From: Jes Sorensen [mailto:jsoren...@fb.com]
On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
Hi Jes,
No, It is clearly
On 05/28/2017 02:03 AM, Or Gerlitz wrote:
On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen wrote:
On 05/27/2017 05:02 PM, Or Gerlitz wrote:
On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen
wrote:
This gets rid of the temporary #ifdef spaghetti and allows the code to
compile without offload
On 05/27/2017 05:02 PM, Or Gerlitz wrote:
On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen wrote:
This gets rid of the temporary #ifdef spaghetti and allows the code to
compile without offload support enabled.
Hi Jes,
I am pretty sure we can do that exercise you're up to without any
spag
This code will not be called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is disabled.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 17 +
.../net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
2 files changed, 18 insertions(+), 1
including eswitch_offloads.o
Unlike the patches that were discussed on the list back in January,
this does not try to remove eswitch support. It simply allows the
offloads to be disabled.
Cheers,
Jes
Jes Sorensen (7):
mlx5: Allow support for eswitch offloads to be disabled
mlx5: eswitch vlan
This allows not compiling this code if eswitch offloads are disabled.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 13 +
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 ++
2 files changed, 15 insertions(+)
diff --git
This code isn't called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS isn't enabled
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h| 20 +++-
.../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 ++
2 files changed, 21 insertions(+),
This allows users to disable eswitch offloads. Follow-on patches will
clean up how the eswitch_offloads code is being called and get rid of all
the #ifdefs.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig| 10 ++
drivers/net/ethernet/mellanox
One more vport related function to disable.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 11 ---
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net
This gets rid of the temporary #ifdef spaghetti and allows the code to
compile without offload support enabled.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 +++-
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 9 -
2 files
These aren't called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS isn't enabled,
so do not build them.
Signed-off-by: Jes Sorensen
---
drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 14 ++
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 --
2 files c
On 05/26/2017 04:29 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen wrote:
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
Hi Jes,
No, It is clearly stated in the commit message :
"The FPGA is a bump-on-the-wire and thus affects operation of
the mlx5_core driv
On 05/25/2017 06:40 AM, Saeed Mahameed wrote:
On Thu, May 25, 2017 at 8:20 AM, Ilan Tayari wrote:
-Original Message-
Can you put it into different driver? Dumping everything into by far
the biggest nic driver already is already huge headache in terms on
maintainability, debugging and ba
tate across all the register access functions.
Arnd
Nice work! This is a textbook example of how to do this the right way!
Reviewed-by: Jes Sorensen
Jes
On 05/16/2017 10:19 AM, Arnd Bergmann wrote:
On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen wrote:
On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote:
On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote:
Passing return values by reference is and always has been a really
poor way to
On 05/16/2017 07:55 AM, Stanislaw Gruszka wrote:
On Mon, May 15, 2017 at 10:39:51AM -0400, David Miller wrote:
Passing return values by reference is and always has been a really
poor way to achieve what these functions are doing.
And frankly, whilst the tool could see what's going on here bette
Larry Finger writes:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declare
Arnd Bergmann writes:
> We accidentally print the rate before we know it for txdesc_v2:
Hi Arnd,
Thanks for the patch - Barry Day already posted a patch for this which
Kalle has applied to the wireless tree.
Cheers,
Jes
>
> wireless/realtek/rtl8xxxu/rtl8xxxu_core.c: In function
> 'rtl8xxxu_f
John Heenan writes:
> Barry Day has submitted real world reports for the 8192eu and 8192cu.
> This needs to be acknowledged. I have submitted real world reports for
> the 8723bu.
Lets get this a little more clear - first of all, I have asked you to
investigate which part resolves the problem. Rat
Dave Jones writes:
> On Fri, Nov 04, 2016 at 09:56:00AM -0400, Jes Sorensen wrote:
>>
>> Joe Perches writes:
>> > On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
>> >> Code is 80 characters wide, and comments are /* */ never the ugly C++
>> >&
> 1 files changed, 35 insertions(+), 30 deletions(-)
Nothing that sticks out to me
Acked-by: Jes Sorensen
Jes
> diff --git a/drivers/net/ethernet/alteon/acenic.c
> b/drivers/net/ethernet/alteon/acenic.c
> index a5c1e29..16f0c70 100644
> --- a/drivers/net/ethernet/alteon/acen
Joe Perches writes:
> On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote:
>> Code is 80 characters wide, and comments are /* */ never the ugly C++
>> crap.
>
> You might look at the recent Linus Torvalds authored commit
> 5e467652ffef (?printk: re-organize log_out
John Heenan writes:
> The rtl8723bu wireless IC shows evidence of a more agressive approach to
> power saving, powering down its RF side when there is no wireless
> interfacing but leaving USB interfacing intact. This makes the wireless
> IC more suitable for use in devices which need to keep thei
John Heenan writes:
> Thanks for your reply.
>
> The code was tested on a Cube i9 which has an internal rtl8723bu.
>
> No other devices were tested.
>
> I am happy to accept in an ideal context hard coding macpower is
> undesirable, the comment is undesirable and it is wrong to assume the
> issue
John Heenan writes:
> Code tests show data returned by rtl8xxxu_read8(priv, REG_CR), used to set
> macpower, is never 0xea. It is only ever 0x01 (first time after modprobe)
> using wpa_supplicant and 0x00 thereafter using wpa_supplicant. These results
> occurs with 'Fix for authentication failure'
Joe Perches writes:
> On Sat, 2016-10-01 at 16:32 -0400, Jes Sorensen wrote:
>> Your output shows it moving to the text segment - if it's in a different
>> segment, eg. rodata, you should use output demonstrating that to justify
>> the change.
>
> For size, rodat
Joe Perches writes:
> On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote:
>> Joe Perches writes:
>> > Make the init arrays const to reduce data.
>> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o*
>> > (allyesconfig: x86-32)
>> > tex
Joe Perches writes:
> Make the init arrays const to reduce data.
>
> $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* (allyesconfig:
> x86-32)
>text data bss dec hex filename
> 80107 13651 58 93816 16e78
> drivers/net/wireless/realtek/rtl8xxxu/
Joe Perches writes:
> On Sat, 2016-09-24 at 14:06 -0500, Larry Finger wrote:
>> On 09/24/2016 12:32 PM, Joe Perches wrote:
> []
>> o Reindent all the switch/case blocks to a more normal
>> kernel style (git diff -w would show no changes here)
>> That sounds like busy work to me, but if you want
Larry Finger writes:
> On 09/24/2016 12:32 PM, Joe Perches wrote:
>> Is there any value in that or is Jes' work going to make
>> doing any or all of this unnecessary and futile?
>
> That is not yet determined. The only driver that is to be replaced at
> this point is rtl8192cu. Jes only has USB I/
Kalle Valo writes:
> Colin Ian King wrote:
>> From: Colin Ian King
>>
>> Trivial fix to spelling mistakes in dev_dbg message.
>>
>> Signed-off-by: Colin Ian King
>> Reviewed-by: Julian Calaby
>
> I assume Jes will take this.
It's on my list, sorry been swamped in LPC stuff and other work th
Kalle Valo writes:
> Baoyou Xie wrote:
>> We get 1 warning about global functions without a declaration
>> in the rtl8xxxu rtl8xxxu_core.c when building with W=1:
>> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c:898:1:
>> warning: no previous prototype for 'rtl8xxxu_gen1_h2c_cmd'
>> [-Wmi
Stefan Lippers-Hollmann writes:
> Hi
>
> On 2016-07-20, Arnd Bergmann wrote:
>> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
>> > Arnd Bergmann writes:
>> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> >
ion to clarify the types and simplify
> the check while removing the warning.
>
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/rtl8192e/rtl819x_Qos.h| 3 ---
> drivers/staging/rtl8192e/rtl819x_TSProc.c | 5 +
> 2 files changed, 5 insertions(+), 3 deletions(-)
Lo
Arnd Bergmann writes:
> On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> Arnd Bergmann writes:
>> Well it really all depends on how much time I have and how much others
>> step up and help contribute to the code. For rtl8xxxu my plans are as
>> f
Arnd Bergmann writes:
> On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote:
>> Arnd Bergmann writes:
>> I think that would be better, albeit not a big issue.
>
> Ok, and since Kalle applied the first patch to his tree, I'm now sending
> a series of three
Arnd Bergmann writes:
> On Tuesday, July 19, 2016 11:46:04 AM CEST Jes Sorensen wrote:
>> > diff --git a/drivers/staging/rtl8192e/rtl819x_TSProc.c
>> > b/drivers/staging/rtl8192e/rtl819x_TSProc.c
>> > index 2c8a526773ed..e0a2fe5e6148 100644
>> > --- a/dr
; 3 files changed, 11 insertions(+), 11 deletions(-)
Looks good to me
Acked-by: Jes Sorensen
Arnd Bergmann writes:
> Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
> incorrect code that results from 'char' being unsigned here, e.g.
>
> staging/rtl8192e/rtl8192e/r8192E_phy.c:1072:36: error: comparison is always
> false due to limited range of data type [-Werror
David Laight writes:
> From: Arnd Bergmann
>> On Wednesday, June 15, 2016 5:10:51 PM CEST Jes Sorensen wrote:
>> >
>> > Arnd,
>> >
>> > rtlwifi and rtl8xxxu are two distinct drivers managed by different
>> > people. I'd be reall
Arnd Bergmann writes:
> Compiling the rtlwifi drivers for ARM with gcc -Wextra warns about lots of
> incorrect code that results from 'char' being unsigned here, e.g.
>
> realtek/rtlwifi/rc.c:113:18: error: comparison is always true due to limited
> range of data type [-Werror=type-limits]
> real
Jes Sorensen writes:
> Colin King writes:
>> From: Colin Ian King
>>
>> path_b_ok is being assigned but immediately after path_a_ok is being
>> compared to the value 0x03. This appears to be a typo on the
>> variable name, compare path_b_ok instead.
&g
Colin King writes:
> From: Colin Ian King
>
> path_b_ok is being assigned but immediately after path_a_ok is being
> compared to the value 0x03. This appears to be a typo on the
> variable name, compare path_b_ok instead.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/net/wireless/realtek/r
Kalle Valo writes:
> Jes Sorensen writes:
>
>> Arnd Bergmann writes:
>>> The references to some arrays in the rtl8xxxu driver were moved inside
>>> of an #ifdef, but the symbols remain outside, resulting in build warnings:
>>>
Arnd Bergmann writes:
> The references to some arrays in the rtl8xxxu driver were moved inside
> of an #ifdef, but the symbols remain outside, resulting in build warnings:
>
> rtl8xxxu/rtl8xxxu.c:1506:33: error: 'rtl8188ru_radioa_1t_highpa_table'
> defined but not used
> rtl8xxxu/rtl8xxxu.c:1431:
Colin King writes:
> From: Colin Ian King
>
> several functions are not initializing a return status in ret
> resulting in garbage to be returned instead of 0 for success.
> Currently, the calls to these functions are not checking the
> return, however, it seems prudent to return the correct stat
Kalle Valo writes:
> David Miller writes:
>
>> From: Kalle Valo
>> Date: Mon, 14 Mar 2016 10:31:48 +0200
>>
>>> I know I'm late now that merge window was opened yesterday but here's
>>> one more set of patches I would like to get to 4.6 still. There isn't
>>> anything controversial so I hope thi
>>>>> "Geert" == Geert Uytterhoeven <[EMAIL PROTECTED]> writes:
Geert> acenic: SET_NETDEV_DEV is always there these days
Geert> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
Signed-off-by: Jes Sorensen <[EMAIL PROTECTED]>
Geert> ---
>>>>> "akpm" == akpm <[EMAIL PROTECTED]> writes:
akpm> From: Michal Piotrowski <[EMAIL PROTECTED]>
akpm> Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>
akpm> Cc: Jeff Garzik <[EMAIL PROTECTED]>
akpm> Cc: Jes Sorensen <[EMAIL
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> Just a reminder to folks out there... Don't send private driver
Jeff> support emails.
Jeff> I receive a lot of email. A lot. Not as much as Linus or
Jeff> Andrew probably, but still sizable. And quite regularly, I will
Jeff> receiv
om .text between
Randy> 'acenic_probe_one' (at offset 0x2409) and 'ace_interrupt'
Randy> WARNING: drivers/net/acenic.o - Section mismatch: reference to
Randy> .init.data:tigon2FwRodata from .text between 'acenic_probe_one'
Randy> (at offset 0x2422) and &#
> "Olaf" == Olaf Hering <[EMAIL PROTECTED]> writes:
Olaf> kmalloc_node returns unaligned pointers on powerpc, when
Olaf> CONFIG_DEBUG_SLAB is enabled. This makes iptables very
Olaf> unhappy. It checks the alignment in
Olaf> net/ipv6/netfilter/ip6_tables.c:check_entry_size_and_hooks().
Olaf> __
88 matches
Mail list logo
