Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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: >>>>

Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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

Re: [PATCH] rtl8xxxu: Fix device info for RTL8192EU devices

On 3/23/21 3:36 PM, Pascal Terjan wrote: > Based on 2001:3319 and 2357:0109 which I used to test the fix and > 0bda:818b and 2357:0108 for which I found efuse dumps online. > > == 2357:0109 == > === Before === > Vendor: Realtek > Product: \x03802.11n NI > Serial: > === After === > Vendor: Realtek

Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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

Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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: >>

Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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

Re: [PATCH RESEND][next] rtl8xxxu: Fix fall-through warnings for Clang

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

Re: [PATCH 117/141] rtl8xxxu: Fix fall-through warnings for Clang

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

Re: [PATCH] rtl8xxxu: remove the unused variable timeout value assignment

On 11/13/20 4:50 AM, xiakaixu1...@gmail.com wrote: > From: Kaixu Xia > > The value of variable timeout is overwritten by the following statement in > rtl8xxxu_gen1_init_aggregation(), so here the value assignment is useless. > Remove it. > > Reported-by: Tosk Robot > Signed-off-by: Kaixu Xia

Re: [RFC] Status of orinoco_usb

d >>> 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 >> that it's still usable.

Re: [PATCH v16 3/3] Input: new da7280 haptic driver

nput/misc/Makefile |1 + > drivers/input/misc/da7280.c | 1840 > +++ > 3 files changed, 1854 insertions(+) > create mode 100644 drivers/input/misc/da7280.c Hi Roy, Overall the driver looks pretty good now. I did find one issue, see below. If you

Re: [PATCH v15 3/3] Input: new da7280 haptic driver

On 6/29/20 9:01 AM, Roy Im wrote: > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with > multiple mode and integrated waveform memory and wideband support. > It communicates via an I2C bus to the device. > > Signed-off-by: Roy Im > --- > v15: > - Removed some defines and updated

Re: [PATCH] rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot

/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 +++ 3 files changed, 5 insertions(+) Looks good to me! If this takes care of the warm boot problem, that's pretty awesome. Signed-off-by: Jes Sorensen Jes

Re: [PATCH] rtl8xxxu: make arrays static, makes object smaller

On 10/7/19 9:53 AM, Colin King wrote: From: Colin Ian King Don't populate const arrays on the stack but instead make them static. Makes the object code smaller by 60 bytes. Before: text data bss dec hex filename 15133 8768 0 239015d5d

Re: [PATCH v3] rtl8xxxu: add bluetooth co-existence support for single antenna

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

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

On 10/2/19 9:19 PM, Chris Chiu wrote: On Wed, Oct 2, 2019 at 11:04 PM Jes Sorensen wrote: In general I think it looks good! One nit below: Sorry I have been traveling for the last three weeks, so just catching up. +void rtl8723bu_set_coex_with_type(struct rtl8xxxu_priv *priv, u8 type

Re: [PATCH v2] rtl8xxxu: add bluetooth co-existence support for single antenna

On 9/10/19 10:50 PM, Chris Chiu wrote: The RTL8723BU suffers the wifi disconnection problem while bluetooth device connected. While wifi is doing tx/rx, the bluetooth will scan without results. This is due to the wifi and bluetooth share the same single antenna for RF communication and they need

Re: [PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

and MCS rate. However, with Realtek's driver, the tx rate observed from > wireshark under the same condition is almost 65Mbps or 72Mbps, which > indicating that rtl8xxxu could still be further improved. > > Signed-off-by: Chris Chiu > Reviewed-by: Daniel Drake I am still traveling a

Re: [Openipmi-developer] [PATCH 0/1] Fix race in ipmi timer cleanup

On 9/14/19 9:08 PM, Corey Minyard wrote: >> >>> >>> {disable,enable}_si_irq() themselves are racy: >>> >>> static inline bool disable_si_irq(struct smi_info *smi_info) >>> { >>> if ((smi_info->io.irq) && (!smi_info->interrupt_disabled)) { >>> smi_info->interrupt_disabled =

Re: [PATCH] rtl8xxxu: add bluetooth co-existence support for single antenna

On 9/3/19 1:37 AM, Chris Chiu wrote: > The RTL8723BU suffers the wifi disconnection problem while bluetooth > device connected. While wifi is doing tx/rx, the bluetooth will scan > without results. This is due to the wifi and bluetooth share the same > single antenna for RF communication and they

Re: [PATCH 0/1] Fix race in ipmi timer cleanup

On 8/28/19 6:32 PM, Corey Minyard wrote: > On Wed, Aug 28, 2019 at 04:36:24PM -0400, Jes Sorensen wrote: >> From: Jes Sorensen >> >> I came across this in 4.16, but I believe the bug is still present >> in current 5.x, even if it is less likely to trigger. >>

[PATCH 1/1] ipmi_si_intf: Fix race in timer shutdown handling

From: Jes Sorensen smi_mod_timer() enables the timer before setting timer_running. This means the timer can be running when we get to stop_timer_and_thread() without timer_running having been set, resulting in del_timer_sync() not being called and the timer being left to cause havoc during

[PATCH 0/1] Fix race in ipmi timer cleanup

From: Jes Sorensen I came across this in 4.16, but I believe the bug is still present in current 5.x, even if it is less likely to trigger. Basially stop_timer_and_thread() only calls del_timer_sync() if timer_running == true. However smi_mod_timer enables the timer before setting timer_running

Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

On 8/12/19 10:32 AM, Kalle Valo wrote: > Jes Sorensen writes: >> Looks good to me! Nice work! I am actually very curious if this will >> improve performance 8192eu as well. >> >> Ideally I'd like to figure out how to make host controlled rates work, >> but in all

Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

e! Nice work! I am actually very curious if this will improve performance 8192eu as well. Ideally I'd like to figure out how to make host controlled rates work, but in all my experiments with that, I never really got it to work well. Signed-off-by: Jes Sorensen Jes > > Notes: >

Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/4/19 11:44 PM, Daniel Drake wrote: > On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen wrote: >> My point is this seems to be very dongle dependent :( We have to be >> careful not breaking it for some users while fixing it for others. > > Do you still have your dev

Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/4/19 10:27 PM, Chris Chiu wrote: > On Fri, Jul 5, 2019 at 12:43 AM Jes Sorensen wrote: >> >> On 7/4/19 6:55 AM, Chris Chiu wrote: >>> The WiFi tx power of RTL8723BU is extremely low after booting. So >>> the WiFi scan gives very limited AP list a

Re: [PATCH v2] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/4/19 6:55 AM, Chris Chiu wrote: > The WiFi tx power of RTL8723BU is extremely low after booting. So > the WiFi scan gives very limited AP list and it always fails to > connect to the selected AP. This module only supports 1x1 antenna > and the antenna is switched to bluetooth due to some

Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/2/19 11:25 PM, Chris Chiu wrote: > On Tue, Jul 2, 2019 at 8:44 PM Jes Sorensen wrote: >> >> On 6/27/19 5:52 AM, Chris Chiu wrote: >>> The WiFi tx power of RTL8723BU is extremely low after booting. So >>> the WiFi scan gives very limited AP list a

Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/3/19 3:42 AM, Daniel Drake wrote: > On Tue, Jul 2, 2019 at 8:42 PM Jes Sorensen wrote: >> We definitely don't want to bring over the vendor code, since it's a >> pile of spaghetti, but we probably need to get something sorted. This >> went down the drain when the bluet

Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 6/27/19 5:52 AM, Chris Chiu wrote: > The WiFi tx power of RTL8723BU is extremely low after booting. So > the WiFi scan gives very limited AP list and it always fails to > connect to the selected AP. This module only supports 1x1 antenna > and the antenna is switched to bluetooth due to some

Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU

On 7/1/19 4:27 AM, Daniel Drake wrote: > Hi Chris, > > On Thu, Jun 27, 2019 at 5:53 PM Chris Chiu wrote: >> The WiFi tx power of RTL8723BU is extremely low after booting. So >> the WiFi scan gives very limited AP list and it always fails to >> connect to the selected AP. This module only

Re: [PATCH 80/87] net: hippi: remove memset after pci_alloc_consistent

> So memset is not needed. > > Signed-off-by: Fuqian Huang > --- > drivers/net/hippi/rrunner.c | 2 -- > 1 file changed, 2 deletions(-) Acked-by: Jes Sorensen > diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c > index 7b9350dbebdd..2a6ec5394966 100644 > -

Re: [RFC PATCH v4] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver

On 5/31/19 5:12 AM, Chris Chiu wrote: > We have 3 laptops which connect the wifi by the same RTL8723BU. > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported. > They have the same problem with the in-kernel rtl8xxxu driver, the > iperf (as a client to an ethernet-connected server)

Re: [PATCH] rtl8xxxu: Add rtl8188ctv support

On 09/04/2018 04:16 AM, Kalle Valo wrote: > Aleksei Mamlin wrote: > >> The Realtek rtl8188ctv (0x0bda:0x018a) is a highly integrated single-chip >> WLAN USB2.0 network interface controller. >> >> Currently rtl8188ctv is supported by rtlwifi driver. >> It is similar to the

Re: [PATCH] rtl8xxxu: Add rtl8188ctv support

On 09/04/2018 04:16 AM, Kalle Valo wrote: > Aleksei Mamlin wrote: > >> The Realtek rtl8188ctv (0x0bda:0x018a) is a highly integrated single-chip >> WLAN USB2.0 network interface controller. >> >> Currently rtl8188ctv is supported by rtlwifi driver. >> It is similar to the

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/23/2018 10:26 AM, Matthew Wilcox wrote: > On Wed, May 23, 2018 at 10:20:10AM -0400, Jes Sorensen wrote: >>> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c >>> @@ -0,0 +1,64 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >> >> Fix the formatting pleas

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/23/2018 10:26 AM, Matthew Wilcox wrote: > On Wed, May 23, 2018 at 10:20:10AM -0400, Jes Sorensen wrote: >>> +++ b/drivers/pci/pcie/aer/aerdrv_stats.c >>> @@ -0,0 +1,64 @@ >>> +// SPDX-License-Identifier: GPL-2.0 >> >> Fix the formatting pleas

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/23/2018 10:26 AM, Alex G. wrote: > On 05/23/2018 09:20 AM, Jes Sorensen wrote: >> On 05/22/2018 06:28 PM, Rajat Jain wrote: >>> new file mode 100644 >>> index ..b9f251992209 >>> --- /dev/null >>> +++ b/drivers/pci/pcie/aer/aerdrv_stat

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/23/2018 10:26 AM, Alex G. wrote: > On 05/23/2018 09:20 AM, Jes Sorensen wrote: >> On 05/22/2018 06:28 PM, Rajat Jain wrote: >>> new file mode 100644 >>> index ..b9f251992209 >>> --- /dev/null >>> +++ b/drivers/pci/pcie/aer/aerdrv_stat

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/22/2018 06:28 PM, Rajat Jain wrote: > Define a structure to hold the AER statistics. There are 2 groups > of statistics: dev_* counters that are to be collected for all AER > capable devices and rootport_* counters that are collected for all > (AER capable) rootports only. Allocate and free

Re: [PATCH 1/5] PCI/AER: Define and allocate aer_stats structure for AER capable devices

On 05/22/2018 06:28 PM, Rajat Jain wrote: > Define a structure to hold the AER statistics. There are 2 groups > of statistics: dev_* counters that are to be collected for all AER > capable devices and rootport_* counters that are collected for all > (AER capable) rootports only. Allocate and free

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] 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 deletion(-) > > diff --git

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: [PATCH] rtl8xxxu: Fix trailing semicolon

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

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] 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 Cc: linux-hi...@sunsite.dk Cc: net

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

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] 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 Cc

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

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] 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] format-security: move static strings to const

On 04/05/2017 05:47 PM, Kees Cook wrote: While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As

Re: [PATCH] format-security: move static strings to const

On 04/05/2017 05:47 PM, Kees Cook wrote: While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As

Re: [PATCHv2] mdadm.c: fix compile error "switch condition has boolean value"

On 03/30/2017 12:58 PM, Gioh Kim wrote: Remove a boolean expression in switch condition to prevent compile error of some compilers, for example, gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2). Signed-off-by: Gioh Kim --- mdadm.c | 14 ++ 1 file

Re: [PATCHv2] mdadm.c: fix compile error "switch condition has boolean value"

On 03/30/2017 12:58 PM, Gioh Kim wrote: Remove a boolean expression in switch condition to prevent compile error of some compilers, for example, gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2). Signed-off-by: Gioh Kim --- mdadm.c | 14 ++ 1 file changed, 6 insertions(+), 8

Re: [PATCH 2/2] mdadm.c: fix compile error "switch condition has boolean value"

On 03/30/2017 03:52 AM, Gioh Kim wrote: On Thu, Mar 30, 2017 at 08:38:35AM +1100, NeilBrown wrote: On Thu, Mar 30 2017, jes.soren...@gmail.com wrote: Gioh Kim writes: Remove a boolean expression in switch condition to prevent compile error of some compilers.

Re: [PATCH 2/2] mdadm.c: fix compile error "switch condition has boolean value"

On 03/30/2017 03:52 AM, Gioh Kim wrote: On Thu, Mar 30, 2017 at 08:38:35AM +1100, NeilBrown wrote: On Thu, Mar 30 2017, jes.soren...@gmail.com wrote: Gioh Kim writes: Remove a boolean expression in switch condition to prevent compile error of some compilers. Please be specific, which

Re: [PATCH 2/2] mdadm.c: fix compile error "switch condition has boolean value"

Gioh Kim writes: > Remove a boolean expression in switch condition > to prevent compile error of some compilers. Please be specific, which compile is unable to handle this? > Signed-off-by: Gioh Kim > --- > mdadm.c | 6 +++--- > 1 file

Re: [PATCH 2/2] mdadm.c: fix compile error "switch condition has boolean value"

Gioh Kim writes: > Remove a boolean expression in switch condition > to prevent compile error of some compilers. Please be specific, which compile is unable to handle this? > Signed-off-by: Gioh Kim > --- > mdadm.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

Re: [PATCH 1/2] super1: replace hard-coded values with bit definitions

Gioh Kim writes: > Some hard-coded values for disk status are replaced > with bit definitions. > > Signed-off-by: Gioh Kim > --- > super1.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Applied! Please use --cover-letter

Re: [PATCH 1/2] super1: replace hard-coded values with bit definitions

Gioh Kim writes: > Some hard-coded values for disk status are replaced > with bit definitions. > > Signed-off-by: Gioh Kim > --- > super1.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Applied! Please use --cover-letter when you send out multi-commit patch sets, which

Re: [PATCHv2 1/2] super1: ignore failfast flag for setting device role

Gioh Kim writes: > There is corner case for setting device role, > if new device has failfast flag. > The failfast flag should be ignored. > > Signed-off-by: Gioh Kim > Signed-off-by: Jack Wang > --- >

Re: [PATCHv2 1/2] super1: ignore failfast flag for setting device role

Gioh Kim writes: > There is corner case for setting device role, > if new device has failfast flag. > The failfast flag should be ignored. > > Signed-off-by: Gioh Kim > Signed-off-by: Jack Wang > --- > super1.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) Applied! Ideally

[PATCH 1/5] notify: Call mutex_destroy() before freeing mutex memory

The conversion of notify from using a spinlock to a mutex missed adding the call mutex_destroy(). Fixes: 986ab09 ("fsnotify: use a mutex instead of a spinlock to protect a groups mark list") Signed-off-by: Jes Sorensen <jsoren...@fb.com> Reviewed-by: Josef Bacik <jba...@fb.

[PATCH 1/5] notify: Call mutex_destroy() before freeing mutex memory

The conversion of notify from using a spinlock to a mutex missed adding the call mutex_destroy(). Fixes: 986ab09 ("fsnotify: use a mutex instead of a spinlock to protect a groups mark list") Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/group.c | 1 + 1 file

[PATCH 5/5] inotify: Avoid taking spinlock for each event processed in read()

Splice off the notification list while processing read events, which allows it to be processed without taking and releasing the spinlock for each event. Signed-off-by: Jes Sorensen <jsoren...@fb.com> Reviewed-by: Josef Bacik <jba...@fb.com> --- fs/notify/inotify/inotify

[PATCH 5/5] inotify: Avoid taking spinlock for each event processed in read()

Splice off the notification list while processing read events, which allows it to be processed without taking and releasing the spinlock for each event. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 28 1 file changed

[PATCH 4/5] inotify: switch get_one_event() to use fsnotify_list_*() helpers

Preparing to switch inotify to code not taking the spinlock for each event in read() Signed-off-by: Jes Sorensen <jsoren...@fb.com> Reviewed-by: Josef Bacik <jba...@fb.com> --- fs/notify/inotify/inotify_user.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) dif

[PATCH 4/5] inotify: switch get_one_event() to use fsnotify_list_*() helpers

Preparing to switch inotify to code not taking the spinlock for each event in read() Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/notify/inotify/inotify_user.c b/fs

[PATCH 3/5] notify: Split up some fsnotify functions

This splits up fsnotify_remove_first_event() and fsnotify_peek_first_event() into a helper function with a wrapper, and introduces two new versions that takes a list instead of the group as argument. Signed-off-by: Jes Sorensen <jsoren...@fb.com> Reviewed-by: Josef Bacik <jba...@fb.com

[PATCH 3/5] notify: Split up some fsnotify functions

This splits up fsnotify_remove_first_event() and fsnotify_peek_first_event() into a helper function with a wrapper, and introduces two new versions that takes a list instead of the group as argument. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/notification.c | 38

[PATCH 2/5] inotify: Use mutex to prevent threaded clients reading events out of order

Introduces mutex in the read() path to prevent a threaded client reading from the same fd consuming events out of order. This will matter when avoiding taking the spinlock when consuming each event in the read() path. Signed-off-by: Jes Sorensen <jsoren...@fb.com> Reviewed-by: Josef Baci

[PATCH 0/5] inofify: Reduce lock contention on read()

, it does increase the overhead for the case where the users tries to read one event at a time. Last, the first patch of the series adds the missing mutex_destoy() for mark_mutex. Thoughts? Jes Jes Sorensen (5): notify: Call mutex_destroy() before freeing mutex memory inotify: Use mutex

[PATCH 2/5] inotify: Use mutex to prevent threaded clients reading events out of order

Introduces mutex in the read() path to prevent a threaded client reading from the same fd consuming events out of order. This will matter when avoiding taking the spinlock when consuming each event in the read() path. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify

[PATCH 0/5] inofify: Reduce lock contention on read()

, it does increase the overhead for the case where the users tries to read one event at a time. Last, the first patch of the series adds the missing mutex_destoy() for mark_mutex. Thoughts? Jes Jes Sorensen (5): notify: Call mutex_destroy() before freeing mutex memory inotify: Use mutex

Re: [PATCH 1/2] super1: ignore failfast flag for setting device role

Gioh Kim writes: > There is corner case for setting device role, > if new device has failfast flag. > The failfast flag should be ignored. > > Signed-off-by: Gioh Kim > Signed-off-by: Jack Wang > --- >

Re: [PATCH 1/2] super1: ignore failfast flag for setting device role

Gioh Kim writes: > There is corner case for setting device role, > if new device has failfast flag. > The failfast flag should be ignored. > > Signed-off-by: Gioh Kim > Signed-off-by: Jack Wang > --- > super1.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 02/13/2017 12:54 AM, zhilong wrote: On 02/13/2017 01:08 PM, zhilong wrote: Hi, Jes; On 01/13/2017 12:41 AM, Jes Sorensen wrote: On 01/11/17 23:24, Guoqing Jiang wrote: On 01/12/2017 12:59 AM, Jes Sorensen wrote: On 01/11/17 11:52, Shaohua Li wrote: On Tue, Jan 10, 2017 at 11:49:04AM

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 02/13/2017 12:54 AM, zhilong wrote: On 02/13/2017 01:08 PM, zhilong wrote: Hi, Jes; On 01/13/2017 12:41 AM, Jes Sorensen wrote: On 01/11/17 23:24, Guoqing Jiang wrote: On 01/12/2017 12:59 AM, Jes Sorensen wrote: On 01/11/17 11:52, Shaohua Li wrote: On Tue, Jan 10, 2017 at 11:49:04AM

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 01/11/17 23:24, Guoqing Jiang wrote: > > > On 01/12/2017 12:59 AM, Jes Sorensen wrote: >> On 01/11/17 11:52, Shaohua Li wrote: >>> On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote: >>>> Jes Sorensen wrote: >>>>> I am pleased to an

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 01/11/17 23:24, Guoqing Jiang wrote: > > > On 01/12/2017 12:59 AM, Jes Sorensen wrote: >> On 01/11/17 11:52, Shaohua Li wrote: >>> On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote: >>>> Jes Sorensen wrote: >>>>> I am pleased to an

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 01/11/17 11:52, Shaohua Li wrote: > On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote: >> Jes Sorensen wrote: >>> I am pleased to announce the availability of >>> mdadm version 4.0 >>> >>> It is available at the usual places: >&

Re: ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

On 01/11/17 11:52, Shaohua Li wrote: > On Tue, Jan 10, 2017 at 11:49:04AM -0600, Bruce Dubbs wrote: >> Jes Sorensen wrote: >>> I am pleased to announce the availability of >>> mdadm version 4.0 >>> >>> It is available at the usual places: >&

ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

. This is my first release of mdadm. Please thank Neil Brown for his previous work as maintainer and blame me for all the bugs I caused since taking over. Jes Sorensen, 2017-01-09

ANNOUNCE: mdadm 4.0 - A tool for managing md Soft RAID under Linux

. This is my first release of mdadm. Please thank Neil Brown for his previous work as maintainer and blame me for all the bugs I caused since taking over. Jes Sorensen, 2017-01-09

Re: PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

MasterPrenium writes: > Hello Guys, > > I've having some trouble on a new system I'm setting up. I'm getting a > kernel BUG message, seems to be related with the use of Xen (when I > boot the system _without_ Xen, I don't get any crash). > Here is configuration : > -

Re: PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

MasterPrenium writes: > Hello Guys, > > I've having some trouble on a new system I'm setting up. I'm getting a > kernel BUG message, seems to be related with the use of Xen (when I > boot the system _without_ Xen, I don't get any crash). > Here is configuration : > - 3x Hard Drives running on

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] 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 property can also be >>

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 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 function >

Re: [mdadm PATCH] Add failfast support.

NeilBrown writes: > Allow per-device "failfast" flag to be set when creating an > array or adding devices to an array. > > When re-adding a device which had the failfast flag, it can be removed > using --nofailfast. > > failfast status is printed in --detail and --examine output.

Re: [mdadm PATCH] Add failfast support.

NeilBrown writes: > Allow per-device "failfast" flag to be set when creating an > array or adding devices to an array. > > When re-adding a device which had the failfast flag, it can be removed > using --nofailfast. > > failfast status is printed in --detail and --examine output. > >

  1   2   3   4   5   6   7   8   >