Re: [PATCH] hippi: fix spelling mistake: "Framming" -> "Framing"

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

Re: [PATCH] rtl8xxxu: Fix trailing semicolon

ipermail/driverdev-devel/2018-January/115390.html > > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Jes Sorensen <jes.soren...@gmail.com> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/r

Re: [net 02/14] Revert "mlx5: move affinity hints assignments to generic code"

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 <s...@grimberg.me> > C

Re: Wifi RTL8723bu driver test: failed to scan

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

Re: mlx5 broken affinity

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/h

Re: mlx5 broken affinity

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.

Re: mlx5 broken affinity

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

Re: mlx5 broken affinity

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 >

Re: mlx5 broken affinity

On 11/01/2017 06:41 PM, Saeed Mahameed wrote: > On Wed, Nov 1, 2017 at 11:20 AM, Jes Sorensen <jsoren...@fb.com> 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 alw

Re: mlx5 broken affinity

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

mlx5 broken affinity

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

Re: [PATCH] drivers/net: hippi: Convert timers to use timer_setup()

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 <j...@trained-monkey.org> Cc: li

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

On 10/11/2017 04:41 AM, Kalle Valo wrote: Jes Sorensen <jes.soren...@gmail.com> 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

Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs

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 Sorensen

Re: [PATCH RFC net-next 4/4] net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig

On 06/13/2017 01:58 PM, Saeed Mahameed wrote: On Mon, Jun 12, 2017 at 9:20 PM, Jes Sorensen <jsoren...@fb.com> 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(switchde

Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic

On 06/13/2017 01:49 PM, Saeed Mahameed wrote: On Mon, Jun 12, 2017 at 8:52 PM, Jes Sorensen <jsoren...@fb.com> 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 conf

Re: [PATCH RFC net-next 4/4] net/mlx5: Add CONFIG_MLX5_ESWITCH Kconfig

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

Re: [PATCH RFC net-next 3/4] net/mlx5: Separate between eswitch and MPFS l2 table logic

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

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 06/07/2017 12:06 AM, Saeed Mahameed wrote: On Wed, Jun 7, 2017 at 12:46 AM, Jes Sorensen <jsoren...@fb.com> 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 co

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 06/05/2017 05:53 PM, Saeed Mahameed wrote: On Mon, Jun 5, 2017 at 11:51 PM, Jes Sorensen <jsoren...@fb.com> wrote: On 06/03/2017 03:37 PM, Or Gerlitz wrote: On Fri, Jun 2, 2017 at 11:22 PM, Jes Sorensen <jsoren...@fb.com> wrote: On 05/28/2017 02:03 AM, Or Gerlitz wrote: On

[PATCH 1/1] mlx5: Allow TC support to be disabled in the build

This provides the option for TC offload support to be disabled in the driver. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 10 ++ drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 ++- drivers/net/ethernet/mellanox/mlx

[PATCH 0/1] Allow TC support to be disabled

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

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 06/03/2017 03:37 PM, Or Gerlitz wrote: On Fri, Jun 2, 2017 at 11:22 PM, Jes Sorensen <jsoren...@fb.com> wrote: On 05/28/2017 02:03 AM, Or Gerlitz wrote: On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen <jes.soren...@gmail.com> wrote: On 05/27/2017 05:02 PM, Or Gerlitz wrote:

Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

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 <jsoren...@fb.com> wrote: On 05/25/2017 06:40 AM, Saeed Mahameed wrote:

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 05/28/2017 02:03 AM, Or Gerlitz wrote: On Sun, May 28, 2017 at 5:23 AM, Jes Sorensen <jes.soren...@gmail.com> wrote: On 05/27/2017 05:02 PM, Or Gerlitz wrote: On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen <jes.soren...@gmail.com> wrote: This gets rid of the temporary #ifd

Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 05/27/2017 05:02 PM, Or Gerlitz wrote: On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen <jes.soren...@gmail.com> 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

[PATCH 3/7] mlx5: Disable {add,del}_offloaded_rule() code if eswitch offloads are disabled

This code will not be called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is disabled. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 17 + .../net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 +- 2 files chang

[PATCH 0/7] mlx5: Make eswitch_offloads a compile option

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

[PATCH 2/7] mlx5: eswitch vlan functionality is only called if SRIOV_OFFLOADS is set

This allows not compiling this code if eswitch offloads are disabled. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 13 + drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 ++ 2 files chang

[PATCH 4/7] mlx5: Stub out eswitch offload vport functions

This code isn't called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS isn't enabled Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/eswitch.h| 20 +++- .../ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2 ++ 2 files changed, 21 inse

[PATCH 1/7] mlx5: Allow support for eswitch offloads to be disabled

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 <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/Kconfig| 10 ++ drive

[PATCH 5/7] mlx5: Stub out create_vport_rx_rule when eswitch_offloads disabled

One more vport related function to disable. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- 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(-)

[PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

This gets rid of the temporary #ifdef spaghetti and allows the code to compile without offload support enabled. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/Makefile | 4 +++- drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads

[PATCH 6/7] mlx5: Stub out sqs2vport functions

These aren't called if CONFIG_MLX5_EN_ESWITCH_OFFLOADS isn't enabled, so do not build them. Signed-off-by: Jes Sorensen <jsoren...@fb.com> --- drivers/net/ethernet/mellanox/mlx5/core/eswitch.h | 14 ++ drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c | 2

Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

On 05/26/2017 04:29 AM, Saeed Mahameed wrote: On Thu, May 25, 2017 at 11:48 PM, Jes Sorensen <jsoren...@fb.com> 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 affect

Re: [for-next 4/6] net/mlx5: FPGA, Add basic support for Innova

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

Re: [PATCH v2 00/10] rt2x00: rt2x00: improve calling conventions for register accessors

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 <jsoren...@fb.com> Jes

Re: [PATCH] rt2x00: improve calling conventions for register accessors

On 05/16/2017 10:19 AM, Arnd Bergmann wrote: On Tue, May 16, 2017 at 3:44 PM, Jes Sorensen <jes.soren...@gmail.com> 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 ha

Re: [PATCH] rt2x00: improve calling conventions for register accessors

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

Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures

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

Re: [PATCH] rtl8xxxu: fix tx rate debug output

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

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

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

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

Dave Jones <s.dave.jo...@gmail.com> writes: > On Fri, Nov 04, 2016 at 09:56:00AM -0400, Jes Sorensen wrote: >> >> Joe Perches <j...@perches.com> writes: >> > On Sun, 2016-10-30 at 19:02 -0400, Jes Sorensen wrote: >> >> Code is 80 characte

Re: [PATCH] net: alteon: acenic: use new api ethtool_{get|set}_link_ksettings

t/alteon/acenic.c | 65 ++--- > 1 files changed, 35 insertions(+), 30 deletions(-) Nothing that sticks out to me Acked-by: Jes Sorensen <jes.soren...@gmail.com> Jes > diff --git a/drivers/net/ethernet/alteon/acenic.c > b/drivers/net/ethernet/alteon/acenic.c > index a5c1e29..16f0c70

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

Joe Perches <j...@perches.com> 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 (?

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

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

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

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

Re: [PATCH 2/2] rtl8xxxu: Fix for bogus data used to determine macpower

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

Re: [PATCH] realtek: rtl8xxxu: Use const init arrays

Joe Perches <j...@perches.com> 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. >

Re: [PATCH] realtek: rtl8xxxu: Use const init arrays

Joe Perches <j...@perches.com> writes: > On Sat, 2016-10-01 at 14:53 -0400, Jes Sorensen wrote: >> Joe Perches <j...@perches.com> writes: >> > Make the init arrays const to reduce data. >> > $ size drivers/net/wireless/realtek/rtl8xxxu/built-in.o* &

Re: [PATCH] realtek: rtl8xxxu: Use const init arrays

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 >

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

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

Re: [PATCH] realtek: Add switch variable to 'switch case not processed' messages

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

Re: rtl8xxxu: fix spelling mistake "firmare" -> "firmware"

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

Re: fix:rtl8xxxu_core: mark symbols static where possible

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

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Stefan Lippers-Hollmann <s@gmx.de> writes: > Hi > > On 2016-07-20, Arnd Bergmann wrote: >> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote: >> > Arnd Bergmann <a...@arndb.de> writes: >> > > On Wednesday, July 20, 2016 7:

Re: [PATCH 3/3] staging/rtl8192e: avoid comparing unsigned type >= 0

hanged, 5 insertions(+), 3 deletions(-) Looks good to me! Acked-by: Jes Sorensen <jes.soren...@redhat.com> > diff --git a/drivers/staging/rtl8192e/rtl819x_Qos.h > b/drivers/staging/rtl8192e/rtl819x_Qos.h > index 463122db6d29..61da8f7475bb 100644 > --- a/drivers/staging/rtl8192e/rtl

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann <a...@arndb.de> writes: > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote: >> Arnd Bergmann <a...@arndb.de> writes: >> Well it really all depends on how much time I have and how much others >> step up and help contribute t

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann <a...@arndb.de> writes: > On Tuesday, July 19, 2016 12:05:00 PM CEST Jes Sorensen wrote: >> Arnd Bergmann <a...@arndb.de> writes: >> I think that would be better, albeit not a big issue. > > Ok, and since Kalle applied the first patch to his tree, I'

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

Arnd Bergmann <a...@arndb.de> 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

Re: [PATCH 3/3] staging/rtl8192u: use s8 instead of char

++--- > 3 files changed, 11 insertions(+), 11 deletions(-) Looks good to me Acked-by: Jes Sorensen <jes.soren...@redhat.com>

Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char

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

Re: [PATCH] rtlwifi: use s8 instead of char

David Laight <david.lai...@aculab.com> 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 >> > p

Re: [PATCH] rtlwifi: use s8 instead of char

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

Re: [PATCH] rtl8xxxu: fix typo on variable name, compare against correct variable

Jes Sorensen <jes.soren...@redhat.com> writes: > Colin King <colin.k...@canonical.com> writes: >> From: Colin Ian King <colin.k...@canonical.com> >> >> path_b_ok is being assigned but immediately after path_a_ok is being >> compared to the value 0x03.

Re: [PATCH] rtl8xxxu: fix typo on variable name, compare against correct variable

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:

Re: [PATCH] rtl8xxxu: hide unused tables

Kalle Valo <kv...@codeaurora.org> writes: > Jes Sorensen <jes.soren...@redhat.com> writes: > >> Arnd Bergmann <a...@arndb.de> writes: >>> The references to some arrays in the rtl8xxxu driver were moved inside >>> of an #ifdef, but the sym

Re: [PATCH] rtl8xxxu: hide unused tables

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 >

Re: [PATCH] rtl8xxxu: fix uninitialized return value in ret

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,

Re: pull-request: wireless-drivers-next 2016-03-14

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

Re: [PATCH] acenic: SET_NETDEV_DEV is always there these days

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 --- Disclaimer: not tested at all Geert --- a/drivers/net/acenic.c +++ b

Re: [patch 04/11] drivers/net/acenic.c Removal of old code

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 PROTECTED] akpm Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Jes

Re: Private driver support emails should be avoided.

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 receive a private

Re: [PATCH] acenic: fix section mismatches

) 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 'ace_interrupt' Randy Signed-off-by: Randy Dunlap [EMAIL PROTECTED] --- Acked-by: Jes Sorensen [EMAIL PROTECTED

Re: kmalloc_node returns unaligned memory

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