Re: [PATCH] ssb: Use true and false for bool variable

On Fri, 5 Feb 2021 14:56:39 +0800 Jiapeng Chong wrote: > Fix the following coccicheck warnings: Acked-by: Michael Büsch -- Michael pgpHQ7VvY18zO.pgp Description: OpenPGP digital signature

Re: [PATCH] ssb: make array pwr_info_offset static const, makes object smaller

Thanks for your contribution. This change makes sense. Kalle, can you please take it? Acked-by: Michael Büsch -- Michael pgpySXyseXA2l.pgp Description: OpenPGP digital signature

Re: [PATCH] char: hw_random: Fix missing check during driver release

On Wed, 26 Dec 2018 11:23:31 -0600 Aditya Pakki wrote: > devres_release can return -ENOENT if the device is not freed. The fix > throws a warning consistent with other invocations. > > Signed-off-by: Aditya Pakki > --- > drivers/char/hw_random/core.c | 6 +- > 1 file changed, 5

Re: [PATCH v3 3/3] b43: Use cordic algorithm from kernel library

On Wed, 14 Nov 2018 20:27:52 +0200 Priit Laes wrote: > Kernel library has a common cordic algorithm which is identical > to internally implementatd one, so use it and drop the duplicate > implementation. In v2 of the series it has been said that: Arend van Spriel wrote: > I recall doing a

Re: [PATCH v3 3/3] b43: Use cordic algorithm from kernel library

On Wed, 14 Nov 2018 20:27:52 +0200 Priit Laes wrote: > Kernel library has a common cordic algorithm which is identical > to internally implementatd one, so use it and drop the duplicate > implementation. In v2 of the series it has been said that: Arend van Spriel wrote: > I recall doing a

Re: [TRIVIAL RFC PATCH] Kconfigs - reduce use of "depends on EXPERT"

On Sun, 29 Jul 2018 11:16:37 -0700 Joe Perches wrote: > (removing a bunch of cc's) > > On Sun, 2018-07-29 at 13:42 +0200, Michael Büsch wrote: > > On Sat, 28 Jul 2018 15:13:00 -0700 > > Joe Perches wrote: > > > > > config SSB_SILENT > > > -

Re: [TRIVIAL RFC PATCH] Kconfigs - reduce use of "depends on EXPERT"

On Sun, 29 Jul 2018 11:16:37 -0700 Joe Perches wrote: > (removing a bunch of cc's) > > On Sun, 2018-07-29 at 13:42 +0200, Michael Büsch wrote: > > On Sat, 28 Jul 2018 15:13:00 -0700 > > Joe Perches wrote: > > > > > config SSB_SILENT > > > -

Re: [TRIVIAL RFC PATCH] Kconfigs - reduce use of "depends on EXPERT"

On Sat, 28 Jul 2018 15:13:00 -0700 Joe Perches wrote: > config SSB_SILENT > - bool "No SSB kernel messages" > - depends on SSB && EXPERT > + bool "No SSB kernel messages" if EXPERT > + depends on SSB > help > This option turns off all Sonics Silicon Backplane

Re: [TRIVIAL RFC PATCH] Kconfigs - reduce use of "depends on EXPERT"

On Sat, 28 Jul 2018 15:13:00 -0700 Joe Perches wrote: > config SSB_SILENT > - bool "No SSB kernel messages" > - depends on SSB && EXPERT > + bool "No SSB kernel messages" if EXPERT > + depends on SSB > help > This option turns off all Sonics Silicon Backplane

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On Sat, 12 May 2018 12:00:07 +0200 Rafał Miłecki wrote: > > Yes, I'm OK with the patch, if we have a third patch that cleans up the > > PCI_DRIVERS_LEGACY dependency by moving it to SSB_PCICORE_HOSTMODE > > where it belongs. (This doesn't need to go into the stable tree.) > >

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On Sat, 12 May 2018 12:00:07 +0200 Rafał Miłecki wrote: > > Yes, I'm OK with the patch, if we have a third patch that cleans up the > > PCI_DRIVERS_LEGACY dependency by moving it to SSB_PCICORE_HOSTMODE > > where it belongs. (This doesn't need to go into the stable tree.) > > We currently

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On Sat, 12 May 2018 10:50:42 +0300 Kalle Valo wrote: > Larry Finger writes: > > > On 05/11/2018 05:13 AM, Kalle Valo wrote: > >> Rafał Miłecki writes: > >> > >>> On 11 May 2018 at 11:17, Rafał Miłecki

Re: [PATCH V2 1/2] Revert "ssb: Prevent build of PCI host features in module"

On Sat, 12 May 2018 10:50:42 +0300 Kalle Valo wrote: > Larry Finger writes: > > > On 05/11/2018 05:13 AM, Kalle Valo wrote: > >> Rafał Miłecki writes: > >> > >>> On 11 May 2018 at 11:17, Rafał Miłecki wrote: > [...] > >>> > >>> As these patches fix regression/build error, I believe

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On Thu, 10 May 2018 13:20:01 +0200 Rafał Miłecki <zaj...@gmail.com> wrote: > On 10 May 2018 at 13:17, Michael Büsch <m...@bues.ch> wrote: > > On Thu, 10 May 2018 13:14:01 +0200 > > Rafał Miłecki <zaj...@gmail.com> wrote: > > >

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On Thu, 10 May 2018 13:20:01 +0200 Rafał Miłecki wrote: > On 10 May 2018 at 13:17, Michael Büsch wrote: > > On Thu, 10 May 2018 13:14:01 +0200 > > Rafał Miłecki wrote: > > > >> From: Rafał Miłecki > >> > >> SSB_PCICORE_HOSTMODE pro

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On Thu, 10 May 2018 13:14:01 +0200 Rafał Miłecki wrote: > From: Rafał Miłecki > > SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported > symbols pcibios_enable_device and register_pci_controller. This code is > supposed to be compiled

Re: [PATCH 4.17 2/2] ssb: make SSB_PCICORE_HOSTMODE depend on SSB = y

On Thu, 10 May 2018 13:14:01 +0200 Rafał Miłecki wrote: > From: Rafał Miłecki > > SSB_PCICORE_HOSTMODE protects MIPS specific code that calls not exported > symbols pcibios_enable_device and register_pci_controller. This code is > supposed to be compiled only with ssb builtin. > > This fixes:

Re: Regression caused by commit 882164a4a928

On Thu, 10 May 2018 11:24:12 +0100 Matt Redfearn wrote: > > Could you please try this? > > > > config SSB_DRIVER_PCICORE_POSSIBLE > > depends on SSB_PCIHOST > > > > config SSB_PCICORE_HOSTMODE > > depends on SSB_DRIVER_PCICORE && SSB_DRIVER_MIPS && (SSB = y) &&

Re: Regression caused by commit 882164a4a928

On Thu, 10 May 2018 11:24:12 +0100 Matt Redfearn wrote: > > Could you please try this? > > > > config SSB_DRIVER_PCICORE_POSSIBLE > > depends on SSB_PCIHOST > > > > config SSB_PCICORE_HOSTMODE > > depends on SSB_DRIVER_PCICORE && SSB_DRIVER_MIPS && (SSB = y) && > > PCI_DRIVERS_LEGACY

Re: Regression caused by commit 882164a4a928

On Wed, 9 May 2018 13:55:43 +0100 Matt Redfearn wrote: > Hi Larry > > On 07/05/18 16:44, Larry Finger wrote: > > Matt, > > > > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features > > in module") appeared to be harmless, it leads to complete failure

Re: Regression caused by commit 882164a4a928

On Wed, 9 May 2018 13:55:43 +0100 Matt Redfearn wrote: > Hi Larry > > On 07/05/18 16:44, Larry Finger wrote: > > Matt, > > > > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features > > in module") appeared to be harmless, it leads to complete failure of > > drivers b43. and

Re: Regression caused by commit 882164a4a928

On Mon, 07 May 2018 22:03:58 +0300 Kalle Valo <kv...@codeaurora.org> wrote: > Michael Büsch <m...@bues.ch> writes: > > > On Mon, 7 May 2018 10:44:34 -0500 > > Larry Finger <larry.fin...@lwfinger.net> wrote: > > > >> Although commit 882

Re: Regression caused by commit 882164a4a928

On Mon, 07 May 2018 22:03:58 +0300 Kalle Valo wrote: > Michael Büsch writes: > > > On Mon, 7 May 2018 10:44:34 -0500 > > Larry Finger wrote: > > > >> Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in > >> module&

Re: Regression caused by commit 882164a4a928

On Mon, 7 May 2018 10:44:34 -0500 Larry Finger wrote: > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in > module") appeared to be harmless, it leads to complete failure of drivers > b43. > config SSB_DRIVER_PCICORE_POSSIBLE >

Re: Regression caused by commit 882164a4a928

On Mon, 7 May 2018 10:44:34 -0500 Larry Finger wrote: > Although commit 882164a4a928 ("ssb: Prevent build of PCI host features in > module") appeared to be harmless, it leads to complete failure of drivers > b43. > config SSB_DRIVER_PCICORE_POSSIBLE > bool > - depends on

Re: [PATCH] net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in dma_tx_fragment

On Tue, 10 Apr 2018 21:54:19 +0800 Jia-Ju Bai wrote: > dma_tx_fragment() is never called in atomic context. > > dma_tx_fragment() is only called by b43legacy_dma_tx(), which is > only called by b43legacy_tx_work(). > b43legacy_tx_work() is only set a parameter of

Re: [PATCH] net: wireless: b43legacy: Replace GFP_ATOMIC with GFP_KERNEL in dma_tx_fragment

On Tue, 10 Apr 2018 21:54:19 +0800 Jia-Ju Bai wrote: > dma_tx_fragment() is never called in atomic context. > > dma_tx_fragment() is only called by b43legacy_dma_tx(), which is > only called by b43legacy_tx_work(). > b43legacy_tx_work() is only set a parameter of INIT_WORK() in >

Re: [PATCH v2] ssb: use put_device() if device_register fail

On Thu, 8 Mar 2018 10:39:49 +0530 Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav

Re: [PATCH v2] ssb: use put_device() if device_register fail

On Thu, 8 Mar 2018 10:39:49 +0530 Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav > --- > changes in v2: > Removed

Re: [PATCH] ssb:: use put_device() if device_register fail

On Wed, 7 Mar 2018 22:46:14 +0530 arvindY wrote: > >> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c > >> index 65420a9..c4449e0 100644 > >> --- a/drivers/ssb/main.c > >> +++ b/drivers/ssb/main.c > >> @@ -521,6 +521,7 @@ static int ssb_devices_register(struct

Re: [PATCH] ssb:: use put_device() if device_register fail

On Wed, 7 Mar 2018 22:46:14 +0530 arvindY wrote: > >> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c > >> index 65420a9..c4449e0 100644 > >> --- a/drivers/ssb/main.c > >> +++ b/drivers/ssb/main.c > >> @@ -521,6 +521,7 @@ static int ssb_devices_register(struct ssb_bus *bus) > >>

Re: [PATCH] ssb:: use put_device() if device_register fail

On Wed, 7 Mar 2018 15:31:30 +0530 Arvind Yadav wrote: > if device_register() returned an error! Always use put_device() > to give up the reference initialized. > > Signed-off-by: Arvind Yadav > --- > drivers/ssb/main.c | 1 + > 1 file

Re: [PATCH] ssb:: use put_device() if device_register fail

On Wed, 7 Mar 2018 15:31:30 +0530 Arvind Yadav wrote: > if device_register() returned an error! Always use put_device() > to give up the reference initialized. > > Signed-off-by: Arvind Yadav > --- > drivers/ssb/main.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git

Re: B43 driver no longer works in Linux 4.15 (bisected)

On Mon, 5 Feb 2018 13:14:28 -0500 Adric Blake wrote: > In the time between Linux 4.15-rc8 and -rc9, my wireless driver, b43, would > no longer load automatically. When I modprobe the b43 (and ssb) modules, > the device still didn't appear in NetworkManager. Comparing the

Re: B43 driver no longer works in Linux 4.15 (bisected)

On Mon, 5 Feb 2018 13:14:28 -0500 Adric Blake wrote: > In the time between Linux 4.15-rc8 and -rc9, my wireless driver, b43, would > no longer load automatically. When I modprobe the b43 (and ssb) modules, > the device still didn't appear in NetworkManager. Comparing the kernel logs > between

Re: [BUG] ssb: Possible sleep-in-atomic bugs in ssb_pcmcia_read8

On Mon, 9 Oct 2017 09:29:17 +0800 Jia-Ju Bai wrote: > According to pcmcia.c, the driver may sleep under a spinlock. > The function call paths are: > ssb_pcmcia_read8 (acquire the spinlock) >select_core_and_segment > ssb_pcmcia_switch_segment >

Re: [BUG] ssb: Possible sleep-in-atomic bugs in ssb_pcmcia_read8

On Mon, 9 Oct 2017 09:29:17 +0800 Jia-Ju Bai wrote: > According to pcmcia.c, the driver may sleep under a spinlock. > The function call paths are: > ssb_pcmcia_read8 (acquire the spinlock) >select_core_and_segment > ssb_pcmcia_switch_segment >ssb_pcmcia_cfg_write >

Re: [PATCH 2/2] b43legacy: fix unitialized reads of ret by initializing the array to zero

On Tue, 5 Sep 2017 19:16:58 +0100 Colin King wrote: > From: Colin Ian King > > The u8 char array ret is not being initialized and elements outside > the range start to end contain just garbage values from the stack. > This results in a later

Re: [PATCH 2/2] b43legacy: fix unitialized reads of ret by initializing the array to zero

On Tue, 5 Sep 2017 19:16:58 +0100 Colin King wrote: > From: Colin Ian King > > The u8 char array ret is not being initialized and elements outside > the range start to end contain just garbage values from the stack. > This results in a later scan of the array to read potentially >

Re: [PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero

On Tue, 5 Sep 2017 19:15:50 +0100 Colin King wrote: > From: Colin Ian King > > The u8 char array ret is not being initialized and elements outside > the range start to end contain just garbage values from the stack. > This results in a later

Re: [PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero

On Tue, 5 Sep 2017 19:15:50 +0100 Colin King wrote: > From: Colin Ian King > > The u8 char array ret is not being initialized and elements outside > the range start to end contain just garbage values from the stack. > This results in a later scan of the array to read potentially >

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

On Fri, 02 Jun 2017 09:18:14 +0800 Jia-Ju Bai wrote: > On 06/02/2017 12:11 AM, Jonathan Corbet wrote: > > On Thu, 01 Jun 2017 09:05:07 +0800 > > Jia-Ju Bai wrote: > > > >> I admit my patches are not well tested, and they may not well fix the bugs. >

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

On Fri, 02 Jun 2017 09:18:14 +0800 Jia-Ju Bai wrote: > On 06/02/2017 12:11 AM, Jonathan Corbet wrote: > > On Thu, 01 Jun 2017 09:05:07 +0800 > > Jia-Ju Bai wrote: > > > >> I admit my patches are not well tested, and they may not well fix the bugs. > >> I am looking forward to opinions and

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Wed, 31 May 2017 19:07:15 -0500 Larry Finger <larry.fin...@lwfinger.net> wrote: > On 05/31/2017 10:32 AM, Michael Büsch wrote: > > On Wed, 31 May 2017 13:26:43 +0300 > > Kalle Valo <kv...@codeaurora.org> wrote: > > > >> Jia-Ju Bai <baijiaju1...

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Wed, 31 May 2017 19:07:15 -0500 Larry Finger wrote: > On 05/31/2017 10:32 AM, Michael Büsch wrote: > > On Wed, 31 May 2017 13:26:43 +0300 > > Kalle Valo wrote: > > > >> Jia-Ju Bai writes: > >> > >>> The driver may

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Thu, 01 Jun 2017 07:27:20 +0300 Kalle Valo <kv...@codeaurora.org> wrote: > Michael Büsch <m...@bues.ch> writes: > > >> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c > >> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Thu, 01 Jun 2017 07:27:20 +0300 Kalle Valo wrote: > Michael Büsch writes: > > >> > --- a/drivers/net/wireless/broadcom/b43legacy/main.c > >> > +++ b/drivers/net/wireless/broadcom/b43legacy/main.c > >> > @@ -2859,7 +2859,9 @@ static

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Wed, 31 May 2017 13:26:43 +0300 Kalle Valo wrote: > Jia-Ju Bai writes: > > > The driver may sleep under a spin lock, and the function call path is: > > b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave) > >

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_op_bss_info_changed

On Wed, 31 May 2017 13:26:43 +0300 Kalle Valo wrote: > Jia-Ju Bai writes: > > > The driver may sleep under a spin lock, and the function call path is: > > b43legacy_op_bss_info_changed (acquire the lock by spin_lock_irqsave) > > b43legacy_synchronize_irq > > synchronize_irq --> may sleep

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

On Wed, 31 May 2017 18:29:07 +0800 Jia-Ju Bai wrote: > The driver may sleep under a spin lock, and the function call path is: > b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave) > b43legacy_radio_set_interference_mitigation >

Re: [PATCH] b43legacy: Fix a sleep-in-atomic bug in b43legacy_attr_interfmode_store

On Wed, 31 May 2017 18:29:07 +0800 Jia-Ju Bai wrote: > The driver may sleep under a spin lock, and the function call path is: > b43legacy_attr_interfmode_store (acquire the lock by spin_lock_irqsave) > b43legacy_radio_set_interference_mitigation >

Re: [PATCH] ssb: Delete an error message for a failed memory allocation in ssb_devices_register()

devwrap = kzalloc(sizeof(*devwrap), GFP_KERNEL); > if (!devwrap) { > - ssb_err("Could not allocate device\n"); > err = -ENOMEM; > goto error; > } This looks good. Acked-by: Michael Büsch <m...@bues.ch> -- Michael pgpU1nQEYRjWo.pgp Description: OpenPGP digital signature

Re: [PATCH] ssb: Delete an error message for a failed memory allocation in ssb_devices_register()

ssb_err("Could not allocate device\n"); > err = -ENOMEM; > goto error; > } This looks good. Acked-by: Michael Büsch -- Michael pgpU1nQEYRjWo.pgp Description: OpenPGP digital signature

Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool

> > @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm) > > default: > > SSB_WARN_ON(1); > > } > > - size = (1 << (size + 1)); > > - > > - return size; > > + return (1 << (size + 1)); > > } > > EXPORT_SYMBOL(ssb_admatch_size); I'm all for

Re: [PATCH] ssb: main.c: This patch removes unnecessary return statement using spatch tool

> > @@ -1272,9 +1272,7 @@ u32 ssb_admatch_size(u32 adm) > > default: > > SSB_WARN_ON(1); > > } > > - size = (1 << (size + 1)); > > - > > - return size; > > + return (1 << (size + 1)); > > } > > EXPORT_SYMBOL(ssb_admatch_size); I'm all for

Re: [v3,1/2] b43: Remove unused phy_a code

On Thu, 16 Jun 2016 18:56:14 +0300 Kalle Valo <kv...@codeaurora.org> wrote: > Michael Büsch <m...@bues.ch> writes: > > > On Thu, 16 Jun 2016 15:23:37 + (UTC) > > Kalle Valo <kv...@codeaurora.org> wrote: > > > >> Guenter Roeck <li...@roe

Re: [v3,1/2] b43: Remove unused phy_a code

On Thu, 16 Jun 2016 18:56:14 +0300 Kalle Valo wrote: > Michael Büsch writes: > > > On Thu, 16 Jun 2016 15:23:37 + (UTC) > > Kalle Valo wrote: > > > >> Guenter Roeck wrote: > >> > gcc-6 reports the following error with -Werror=unused-const-

Re: [v3,1/2] b43: Remove unused phy_a code

r: > > 'b43_phyops_a' defined but not used > > > > Per Michael Büsch: "All a-phy code is usused", so remove it all, > > and move the remaining Type-G initialization code into phy_g.c. > > > > Reported-by: Fengguang Wu <fengguang...@intel.com&g

Re: [v3,1/2] b43: Remove unused phy_a code

On Thu, 16 Jun 2016 15:23:37 + (UTC) Kalle Valo wrote: > Guenter Roeck wrote: > > gcc-6 reports the following error with -Werror=unused-const-variable. > > > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > > 'b43_phyops_a' defined but not used

Re: [PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style

On Sat, 4 Jun 2016 12:50:05 +0100 Hugh Sipière wrote: > These lines just have unsigned gpio rather than unsigned int gpio. > I changed it to suit the coding style. > > Signed-off-by: Hugh Sipière Acked-by: Michael Buesch Please send

Re: [PATCH] drivers: ssb: Change bare unsigned to unsigned int to suit coding style

On Sat, 4 Jun 2016 12:50:05 +0100 Hugh Sipière wrote: > These lines just have unsigned gpio rather than unsigned int gpio. > I changed it to suit the coding style. > > Signed-off-by: Hugh Sipière Acked-by: Michael Buesch Please send this to the MIPS tree, because this basically is

Re: [PATCH] drivers: ssb: Fix comments to suit coding style

On Sat, 4 Jun 2016 12:32:13 +0100 Hugh Sipière wrote: > I changed it so that these two comments do not end on a line with text. > > Signed-off-by: Hugh Sipière > --- > drivers/ssb/driver_gpio.c | 6 -- > 1 file changed, 4 insertions(+), 2

Re: [PATCH] drivers: ssb: Fix comments to suit coding style

On Sat, 4 Jun 2016 12:32:13 +0100 Hugh Sipière wrote: > I changed it so that these two comments do not end on a line with text. > > Signed-off-by: Hugh Sipière > --- > drivers/ssb/driver_gpio.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git

Re: [PATCH v2 1/2] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 21:11:51 -0700 Guenter Roeck wrote: > +static void __b43_phy_initg(struct b43_wldev *dev) > +{ > + struct b43_phy *phy = >phy; > + > + might_sleep(); > + > + if (phy->rev >= 6) { > + if (b43_phy_read(dev, B43_PHY_ENCORE) &

Re: [PATCH v2 1/2] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 21:11:51 -0700 Guenter Roeck wrote: > +static void __b43_phy_initg(struct b43_wldev *dev) > +{ > + struct b43_phy *phy = >phy; > + > + might_sleep(); > + > + if (phy->rev >= 6) { > + if (b43_phy_read(dev, B43_PHY_ENCORE) & B43_PHY_ENCORE_EN) > +

Re: [PATCH] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 14:32:46 -0700 Guenter Roeck wrote: > gcc-6 reports the following error with -Werror=unused-const-variable. > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > 'b43_phyops_a' defined but not used > > Turns out a lot of code in this file

Re: [PATCH] b43: Remove unused phy_a code

On Fri, 3 Jun 2016 14:32:46 -0700 Guenter Roeck wrote: > gcc-6 reports the following error with -Werror=unused-const-variable. > > drivers/net/wireless/broadcom/b43/phy_a.c:576:40: error: > 'b43_phyops_a' defined but not used > > Turns out a lot of code in this file is unused, so let's

Re: [PATCH] b43: fix memory leak

On Fri, 19 Feb 2016 20:37:18 +0530 Sudip Mukherjee wrote: > > https://patchwork.kernel.org/patch/8049041/ > > I have an old laptop running on 800Mhz CPU. It has "Broadcom BCM4311 > [14e4:4311] (rev 01)". > I will try to test it on this weekend. Any news on this

Re: [PATCH] b43: fix memory leak

On Fri, 19 Feb 2016 20:37:18 +0530 Sudip Mukherjee wrote: > > https://patchwork.kernel.org/patch/8049041/ > > I have an old laptop running on 800Mhz CPU. It has "Broadcom BCM4311 > [14e4:4311] (rev 01)". > I will try to test it on this weekend. Any news on this one? -- Michael

Re: [PATCH] b43: fix memory leak

On Thu, 18 Feb 2016 18:04:36 +0530 Sudip Mukherjee wrote: > From: Sudip Mukherjee > > On error we jumped to the label bcma_out and returned the error code but > we missed freeing dev. > > Signed-off-by: Sudip Mukherjee

Re: [PATCH] b43: fix memory leak

On Thu, 18 Feb 2016 18:04:36 +0530 Sudip Mukherjee wrote: > From: Sudip Mukherjee > > On error we jumped to the label bcma_out and returned the error code but > we missed freeing dev. > > Signed-off-by: Sudip Mukherjee > --- > drivers/net/wireless/broadcom/b43/main.c | 1 + > 1 file

Re: [PATCH] m32r: Fix clearing of thread info fault code

On Thu, 19 Nov 2015 15:08:32 -0800 Andrew Morton wrote: > I don't think we should apply this unless someone can runtime test it. > Presumably the current code works OK, but we just don't know what > nasties the fixed version might expose. I fully agree. But who can test it? > The best I can

Re: [PATCH] m32r: Fix clearing of thread info fault code

On Thu, 19 Nov 2015 15:08:32 -0800 Andrew Morton wrote: > I don't think we should apply this unless someone can runtime test it. > Presumably the current code works OK, but we just don't know what > nasties the fixed version might expose. I fully agree. But who can

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] sh: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] nvidia/noveau: Fix color mask

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Accordingly ~(~0 >> x) will always be zero. Hence 'mask' will always be zero in this case. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] nvidia/noveau: Fix color mask

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Accordingly ~(~0 >> x) will always be zero. Hence 'mask' will always be zero in this case. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] sh: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

Re: [PATCH] ssb: mark ssb_bus_register as __maybe_unused

On Tue, 03 Nov 2015 17:42:26 +0100 Arnd Bergmann wrote: > On Tuesday 03 November 2015 17:27:21 Michael Büsch wrote: > > On Tue, 03 Nov 2015 16:05:51 +0100 > > Arnd Bergmann wrote: > > > > > The SoC variant of the ssb code is now optional like the other > &

Re: [PATCH] ssb: mark ssb_bus_register as __maybe_unused

On Tue, 03 Nov 2015 16:05:51 +0100 Arnd Bergmann wrote: > The SoC variant of the ssb code is now optional like the other > ones, which means we can build the framwork without any > front-end, but that results in a warning: > > drivers/ssb/main.c:616:12: warning: 'ssb_bus_register' defined but

Re: [PATCH] ssb: mark ssb_bus_register as __maybe_unused

On Tue, 03 Nov 2015 16:05:51 +0100 Arnd Bergmann wrote: > The SoC variant of the ssb code is now optional like the other > ones, which means we can build the framwork without any > front-end, but that results in a warning: > > drivers/ssb/main.c:616:12: warning:

Re: [PATCH] ssb: mark ssb_bus_register as __maybe_unused

On Tue, 03 Nov 2015 17:42:26 +0100 Arnd Bergmann <a...@arndb.de> wrote: > On Tuesday 03 November 2015 17:27:21 Michael Büsch wrote: > > On Tue, 03 Nov 2015 16:05:51 +0100 > > Arnd Bergmann <a...@arndb.de> wrote: > > > > > The SoC variant of t

Re: [PATCH v2 3/3] net: wireless: b43: Statics are init to 0

On Mon, 19 Oct 2015 17:02:23 +0100 Paul McQuade wrote: > diff --git a/drivers/net/wireless/b43/phy_lp.c > b/drivers/net/wireless/b43/phy_lp.c > index 058a9f2..086f0ba 100644 > --- a/drivers/net/wireless/b43/phy_lp.c > +++ b/drivers/net/wireless/b43/phy_lp.c > @@ -2502,7 +2502,7 @@ static int

Re: [PATCH v2 2/3] net: wireless: b43: Coding Style

On Mon, 19 Oct 2015 17:02:22 +0100 Paul McQuade wrote: > Fixed Pointer Coding Style > > Signed-off-by: Paul McQuade > --- > drivers/net/wireless/b43/main.c | 6 +++--- > drivers/net/wireless/b43/main.h | 2 +- > drivers/net/wireless/b43/xmit.h | 2 +- > 3 files changed, 5 insertions(+), 5

Re: [PATCH v2 2/3] net: wireless: b43: Coding Style

On Mon, 19 Oct 2015 17:02:22 +0100 Paul McQuade wrote: > Fixed Pointer Coding Style > > Signed-off-by: Paul McQuade > --- > drivers/net/wireless/b43/main.c | 6 +++--- > drivers/net/wireless/b43/main.h | 2 +- > drivers/net/wireless/b43/xmit.h | 2

Re: [PATCH v2 3/3] net: wireless: b43: Statics are init to 0

On Mon, 19 Oct 2015 17:02:23 +0100 Paul McQuade wrote: > diff --git a/drivers/net/wireless/b43/phy_lp.c > b/drivers/net/wireless/b43/phy_lp.c > index 058a9f2..086f0ba 100644 > --- a/drivers/net/wireless/b43/phy_lp.c > +++ b/drivers/net/wireless/b43/phy_lp.c > @@ -2502,7

Re: [PATCH 2/3] net: wireless: b43: Fixed Pointer issue

On Sun, 18 Oct 2015 00:01:37 +0100 Paul McQuade wrote: > Moved around pointer to avoid ERROR > > Signed-off-by: Paul McQuade > --- > drivers/net/wireless/b43/dma.h | 14 +++--- > drivers/net/wireless/b43/main.c | 6 +++--- > drivers/net/wireless/b43/main.h | 2 +- >

Re: [PATCH 2/3] net: wireless: b43: Fixed Pointer issue

On Sun, 18 Oct 2015 00:01:37 +0100 Paul McQuade wrote: > Moved around pointer to avoid ERROR > > Signed-off-by: Paul McQuade > --- > drivers/net/wireless/b43/dma.h | 14 +++--- > drivers/net/wireless/b43/main.c | 6 +++--- >

Re: [PATCH 1/1] ssb: remove unncessary out label

On Fri, 19 Jun 2015 14:23:45 +0530 Maninder Singh wrote: > This patch removes unnecessary label "out" and > some restructring for using device_create_file directly. > > Signed-off-by: Maninder Singh > Reviewed-by: Rohit Thapliyal > --- > drivers/ssb/pci.c |8 +--- > 1 files changed,

Re: [PATCH 1/1] ssb: remove unncessary out label

On Fri, 19 Jun 2015 14:23:45 +0530 Maninder Singh maninder...@samsung.com wrote: This patch removes unnecessary label out and some restructring for using device_create_file directly. Signed-off-by: Maninder Singh maninder...@samsung.com Reviewed-by: Rohit Thapliyal r.thapli...@samsung.com

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] sh: Fix clearing of thread info fault code

The expression (~0 >> x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] sh: Fix clearing of thread info fault code

The expression (~0 x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

[PATCH] m32r: Fix clearing of thread info fault code

The expression (~0 x) will always yield all-ones, because the right shift is an arithmetic right shift that will always shift ones in. Hence the old fault code bits will not be cleared before being ORed with the new fault code. Fix this by forcing a logical right shift instead of an arithmetic

Re: [PATCH 5/7] ssb: Use bool function return values of true/false not 1/0

On Mon, 30 Mar 2015 10:43:21 -0700 Joe Perches wrote: > Use the normal return values for bool functions > > Signed-off-by: Joe Perches > --- > drivers/ssb/driver_gige.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/ssb/driver_gige.c

Re: [PATCH 5/7] ssb: Use bool function return values of true/false not 1/0

On Mon, 30 Mar 2015 10:43:21 -0700 Joe Perches j...@perches.com wrote: Use the normal return values for bool functions Signed-off-by: Joe Perches j...@perches.com --- drivers/ssb/driver_gige.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ssb/driver_gige.c

Re: [PATCH] bcma: Kconfig: Let it depend on PCI

On Wed, 4 Mar 2015 14:36:10 +0100 Rafał Miłecki 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 and without any

  1   2   >