[PATCH] brcmfmac: fix error handling of irq_of_parse_and_map

Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating failure, so testing for negative result never works. Signed-off-by: Dmitry Torokhov d...@chromium.org --- Not tested, found by casual code inspection. drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++-- 1 file changed

[PATCH] NFC: pn544: i2c: fix error handling of irq_of_parse_and_map

Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating failure, so testing for negative result never works. Signed-off-by: Dmitry Torokhov d...@chromium.org --- Not tested, found by casual code inspection. drivers/nfc/pn544/i2c.c | 9 - 1 file changed, 4 insertions

[PATCH] NFC: st21nfca: fix error handling of irq_of_parse_and_map

Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating failure, so testing for negative result never works. Also report error returned by devm_gpio_request_one instead of clobbering it with -ENODEV. Signed-off-by: Dmitry Torokhov d...@chromium.org --- drivers/nfc/st21nfca

[PATCH] NFC: st21nfcb: fix error handling of irq_of_parse_and_map

Return value of irq_of_parse_and_map() is unsigned int, with 0 indicating failure, so testing for negative result never works. Also report error returned by devm_gpio_request_one instead of clobbering it with -ENODEV. Signed-off-by: Dmitry Torokhov d...@chromium.org --- Not tested, found

Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage

On Wed, Dec 09, 2015 at 02:08:35PM +0100, Linus Walleij wrote: > This removes the use of container_of() constructions from *all* > GPIO drivers in the kernel. It is done by instead adding an > optional void *data pointer to the struct gpio_chip and an > accessor function, gpiochip_get_data() to

Re: [PATCH 000/182] Rid struct gpio_chip from container_of() usage

On Mon, Dec 14, 2015 at 1:18 AM, Linus Walleij <linus.wall...@linaro.org> wrote: > On Wed, Dec 9, 2015 at 8:30 PM, Dmitry Torokhov > <dmitry.torok...@gmail.com> wrote: >> On Wed, Dec 09, 2015 at 02:08:35PM +0100, Linus Walleij wrote: >>> This removes the use of

Re: [RFC v0 3/8] firmware: Factor out firmware load helpers

On Thu, Jul 28, 2016 at 09:55:07AM +0200, Daniel Wagner wrote: > +int __firmware_stat_wait(struct firmware_stat *fwst, > + long timeout) > +{ > + int err; > + err = swait_event_interruptible_timeout(fwst->wq, > +

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

Andersson wrote: >> >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote: >> >> >> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: >> >>>> From: Daniel Wagner <daniel.wag...@bmw-carit.de> >> >>>&

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On July 30, 2016 5:42:41 AM PDT, Arend van Spriel <arend.vanspr...@broadcom.com> wrote: >+ Luis (again) ;-) > >On 29-07-16 08:13, Daniel Wagner wrote: >> On 07/28/2016 09:01 PM, Bjorn Andersson wrote: >>> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote: >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: >> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: >> >>>The sysdata API's main goal

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 05:55:40PM +0200, Luis R. Rodriguez wrote: > > I accept all help and would be glad to make enhancements instead of > the old API through new API. The biggest thing here first I think is > adding devm support, that I think should address what seemed to be > the need to add

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 01:43:31PM +0200, Arend van Spriel wrote: > On 03-08-16 09:42, Dmitry Torokhov wrote: > > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez <mcg...@kernel.org> > > wrote: > >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

Wagner wrote: > > > > On 07/28/2016 09:01 PM, Bjorn Andersson wrote: > > > >> On Thu 28 Jul 11:33 PDT 2016, Dmitry Torokhov wrote: > > > >> > > > >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: > > > >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote: > From: Daniel Wagner > > Loading firmware is an operation many drivers implement in various ways > around the completion API. And most of them do it almost in the same > way. Let's reuse the firmware_stat

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

On Tue, Jan 17, 2017 at 11:48:22AM -0800, Brian Norris wrote: > On Sun, Jan 15, 2017 at 04:54:52PM -0800, Dmitry Torokhov wrote: > > On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote: > > > The following sequence occurs when using IEEE power-save on 8997: > >

Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

Hi Amit, On Wed, Oct 26, 2016 at 03:23:08PM +, Amitkumar Karwar wrote: > > This race won't occur. At this point of time(i.e while calling > mwifiex_shutdown_drv() in deinit), following things are completed. We don't > expect mwifiex_main_process() to be scheduled. > 1) Connection to peer

Re: [PATCH] mwifiex: don't do unbalanced free()'ing in cleanup_if()

On Wed, Oct 26, 2016 at 04:29:20PM -0700, Brian Norris wrote: > The cleanup_if() callback is the inverse of init_if(). We allocate our > 'card' interface structure in the probe() function, but we free it in > cleanup_if(). That gives a few problems: > (a) we leak this memory if probe() fails

Re: [PATCH] mwifiex: don't do unbalanced free()'ing in cleanup_if()

On Wed, Oct 26, 2016 at 04:43:54PM -0700, Brian Norris wrote: > On Wed, Oct 26, 2016 at 04:35:54PM -0700, Dmitry Torokhov wrote: > > On Wed, Oct 26, 2016 at 04:29:20PM -0700, Brian Norris wrote: > > > > diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c > > >

Re: [PATCH 3/5] mwifiex: do not free firmware dump memory in shutdown_drv

On Mon, Oct 24, 2016 at 07:51:30PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > mwifiex_upload_device_dump() already takes care of freeing firmware dump > memory. Doing the same thing in mwifiex_shutdown_drv() is redundant. > > Signed-off-by: Xinming Hu

Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > This variable is guarded by spinlock at all other places. This patch > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > Signed-off-by: Amitkumar Karwar > --- >

Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

On Mon, Oct 24, 2016 at 12:19:15PM -0700, Brian Norris wrote: > On Mon, Oct 24, 2016 at 07:51:29PM +0530, Amitkumar Karwar wrote: > > This variable is guarded by spinlock at all other places. This patch > > takes care of missing spinlock usage in mwifiex_shutdown_drv(). > > > > Signed-off-by:

Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card

On Mon, Oct 24, 2016 at 07:51:32PM +0530, Amitkumar Karwar wrote: > From: Xinming Hu > > This patch ensures to wait for firmware dump completion in > mwifiex_remove_card(). > > For sdio interface, reset_trigger variable is used to identify > if mwifiex_sdio_remove() is called

Re: [PATCH 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

On Tue, Oct 25, 2016 at 04:11:14PM +, Amitkumar Karwar wrote: > Hi Dmitry, > > > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > > Sent: Tuesday, October 25, 2016 5:28 AM > > To: Brian Norris > > Cc: Amitkumar Karwar; linux-wireless@vger.

Re: [PATCH v4 1/3] mwifiex: reset card->adapter during device unregister

@vger.kernel.org; Cathy Luo; Nishant Sarmukadam; > > raja...@google.com; Xinming Hu; abhishe...@google.com; Dmitry Torokhov > > Subject: Re: [PATCH v4 1/3] mwifiex: reset card->adapter during device > > unregister > > > > Hi Amit, > > > > On Thu, Oct

Re: [PATCH v4 3/3] mwifiex: Enable WoWLAN for both sdio and pcie

On Tue, Nov 15, 2016 at 07:06:04PM +0530, Amitkumar Karwar wrote: > From: Rajat Jain > > Commit ce4f6f0c353b ("mwifiex: add platform specific wakeup interrupt > support") added WoWLAN feature only for sdio. This patch moves that > code to the common module so that all the

Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

On Thu, Nov 03, 2016 at 08:34:06AM +, Xinming Hu wrote: > Hi Dmitry, > > > -Original Message- > > From: linux-wireless-ow...@vger.kernel.org > > [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of Dmitry Torokhov > > Sent: 2016年10月28日 1:44 > >

Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

On Thu, Nov 3, 2016 at 12:27 PM, Brian Norris <briannor...@chromium.org> wrote: > On Thu, Nov 03, 2016 at 09:15:04AM -0700, Dmitry Torokhov wrote: >> On Thu, Nov 03, 2016 at 08:34:06AM +, Xinming Hu wrote: >> > > -Original Message- >> > > Fro

Re: [PATCH v2 2/5] mwifiex: use spinlock for 'mwifiex_processing' in shutdown_drv

Hi Amit, On Thu, Oct 27, 2016 at 02:42:40PM +0530, Amitkumar Karwar wrote: > This variable is guarded by spinlock at all other places. This patch > takes care of missing spinlock usage in mwifiex_shutdown_drv(). Since in the previous discussion you stated that we inhibit interrupts and flush the

Re: [PATCH v6] mwifiex: parse device tree node for PCIe

On Wed, Oct 26, 2016 at 01:17:36PM -0700, Brian Norris wrote: > Hi Rajat, > > On Fri, Oct 21, 2016 at 02:21:09PM -0700, Rajat Jain wrote: > > From: Xinming Hu > > > > This patch derives device tree node from pcie bus layer framework, and > > fixes a minor memory leak in

Re: [PATCH v6] mwifiex: parse device tree node for PCIe

On Wed, Oct 26, 2016 at 01:56:34PM -0700, Brian Norris wrote: > On Wed, Oct 26, 2016 at 01:51:48PM -0700, Rajat Jain wrote: > >On Wed, Oct 26, 2016 at 1:46 PM, Dmitry Torokhov > ><dmitry.torok...@gmail.com> wrote: > > On Wed, Oct 26, 2016 at 01:17:36P

Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister

Hi Brian, On Mon, Oct 10, 2016 at 4:47 PM, Brian Norris <briannor...@chromium.org> wrote: > Hi Dmitry, > > On Mon, Oct 10, 2016 at 04:43:06PM -0700, Dmitry Torokhov wrote: >> On Thu, Oct 6, 2016 at 6:03 AM, Amitkumar Karwar <akar...@marvell.com> wrote: &g

Re: [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister

On Thu, Oct 6, 2016 at 6:03 AM, Amitkumar Karwar wrote: > Hi Brian, > >> From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- >> ow...@vger.kernel.org] On Behalf Of Brian Norris >> Sent: Wednesday, October 05, 2016 10:00 PM >> To: Amitkumar Karwar >> Cc:

Re: [PATCH v2 2/3] mwifiex: pcie: don't loop/retry interrupt status checks

On Fri, Jan 13, 2017 at 03:35:37PM -0800, Brian Norris wrote: > The following sequence occurs when using IEEE power-save on 8997: > (a) driver sees SLEEP event > (b) driver issues SLEEP CONFIRM > (c) driver recevies CMD interrupt; within the interrupt processing loop, > we do (d) and (e): >

Re: [PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

On Thu, Mar 16, 2017 at 03:58:52PM +0530, Amitkumar Karwar wrote: > We observed a SHUTDOWN command timeout during reboot stress test > due to a corner case firmware bug. It leads to use-after-free on > adapter structure pointer and crash. > > Let's add MWIFIEX_IFACE_WORK_DONT_RUN work flag to

Re: [PATCH 3/3] mwifiex: pcie: avoid hardcode wifi-only firmware name

On Thu, Mar 30, 2017 at 2:19 AM, Xinming Hu wrote: > From: Xinming Hu > > Wifi-only firmware name should be chipset specific. > > Signed-off-by: Xinming Hu > Signed-off-by: Amitkumar Karwar > --- >

Re: [PATCH 1/3] mwifiex: remove unnecessary wakeup interrupt number sanity check

terrupt handler is called, we know that the wakeup interrupt number is valid, there is no need to check it." Otherwise: Reviewed-by: Dmitry Torokhov <d...@chromium.org> > > Signed-off-by: Xinming Hu <h...@marvell.com> > Signed-off-by: Amitkumar Karwar <akar...@marvell.com

Re: [PATCH 2/3] mwifiex: using general print function during device intialization

On Thu, Mar 30, 2017 at 2:19 AM, Xinming Hu wrote: > From: Xinming Hu > > adapter->dev is initialized after mwifiex_register done, before that > print message by general pr_* function No, we should move away from naked pr_*() as much as possible. Please

Re: [RFC PATCH] Revert "mwifiex: fix system hang problem after resume"

lly* stuck in host-sleep mode. So > instead, this is unnecessarily creating scenarios where we can't recover > Wifi. > > Cc: Amitkumar Karwar <akar...@marvell.com> > Signed-off-by: Brian Norris <briannor...@chromium.org> FWIW: Reviewed-by: Dmitry Torokhov <dmitry.torok...@gmail.com>

Re: [PATCH v2 2/4] mwifiex: fall back mwifiex_dbg to pr_info when adapter->dev not set

Hi Xinming, On Fri, Apr 7, 2017 at 3:51 AM, Xinming Hu wrote: > From: Xinming Hu > > mwifiex_dbg will do nothing before adapter->dev get assigned. several logs > lost in this case. it can be avoided by fall back to pr_info. > > Signed-off-by: Xinming Hu

Re: Re: [PATCH] mwifiex: add tdls uapsd support module parameter

r...@chromium.org] >> > Sent: 2017年7月20日 4:10 >> > To: Xinming Hu >> > Cc: Linux Wireless; Kalle Valo; Dmitry Torokhov; raja...@google.com; >> > Zhiyuan >> > Yang; Tim Song; Cathy Luo; Xinming Hu >> > S

Re: [PATCH] mwifiex: correct channel stat buffer overflows

t; them soon. But I realized this one is a nasty bug (with a trivial fix), so > it's > probably best to get this out the door quickly. This does make sense to me. Reviewed-by: Dmitry Torokhov <dmitry.torok...@gmail.com> > > drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2

Re: [PATCH v3 2/2] mwifiex: pcie: add card_reset() support

On Mon, May 01, 2017 at 12:37:00PM -0700, Brian Norris wrote: > Similar to the SDIO driver, we should implement this so that we will > automatically reset the device whenever there's a command timeout or > similar. > > Signed-off-by: Brian Norris <briannor...@chromium.org>

Re: [PATCH v3 1/2] mwifiex: initiate card-specific work atomically

) > will be cleared by then), but it's still an anti-pattern. > > Rewrite this to use the atomic test_and_set_bit() helper instead. > > Signed-off-by: Brian Norris <briannor...@chromium.org> Reviewed-by: Dmitry Torokhov <dmitry.torok...@gmail.com> > --- > v3: