Re: brcm4330 fails to load on newer kernels

Hi Arend, On Thu, Jul 28, 2016 at 3:37 PM, Arend van Spriel wrote: > Hi Fabio, > > So this is another fine example of firmware API not able to deliver. I > think in all these kernels you have the same issue. The problem is that > the order of events upon kernel

Re: [RFC] ath10k: silence firmware file probing warnings

On Thu, Jul 28, 2016 at 09:23:35PM +0200, Arend van Spriel wrote: > On 23-07-16 00:05, Luis R. Rodriguez wrote: > > The firmware API is a mess and I've been trying to correct that > > with a more flexible API. <-- snip --> > > Extensions to the fw API are IMHO best done through a newer flexible

Re: [RFC] ath10k: silence firmware file probing warnings

On 23-07-16 00:15, Luis R. Rodriguez wrote: > On Fri, Jul 22, 2016 at 12:26:00PM +0200, Stanislaw Gruszka wrote: >> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote: >>> + Luis >>> >>> On 21-7-2016 13:51, Stanislaw Gruszka wrote: (cc: firmware and brcmfmac maintainers)

Re: [RFC] ath10k: silence firmware file probing warnings

On 23-07-16 00:05, Luis R. Rodriguez wrote: > On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote: >> + Luis >> >> On 21-7-2016 13:51, Stanislaw Gruszka wrote: >>> (cc: firmware and brcmfmac maintainers) >>> >>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:

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

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 > > [..] > > Do not quite like it... I'd rather asynchronous request give out a > firmware status pointer that could be used

Re: brcm4330 fails to load on newer kernels

On 27-07-16 22:57, Fabio Estevam wrote: > Hi Arend, > > On Wed, Jul 27, 2016 at 5:51 PM, Arend van Spriel > wrote: >> On 27-07-16 00:35, Fabio Estevam wrote: >>> Hi, >>> >>> On a imx6sl-warp board with a brcm4330 I get the following results >>> depending on the

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: [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: staging: wilc1000: Reduce scope for a few variables in mac_ioctl()

> Which circumstances do "not any sense at all" imply? Should the expression 'strlen("RSSI")' be passed for the parameter 'length' instead? > I suggest to fix this since it is indeed a bug, We can agree that this function implementation was broken for a while there. > instead of doing

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

On Thu, 2016-07-28 at 09:55 +0200, Daniel Wagner wrote: > From: Daniel Wagner > > Factor out the firmware loading synchronization code in order to > allow > drivers to reuse it. This also documents more clearly what is > happening. This is especial useful the drivers

Re: [RFC v0 4/8] Input: goodix: use firmware_stat instead of completion

Looking at the API, I really don't like the mixing of namespaces. Either it's fw_ or it's firmware_ but not a mix of both. I agree, that was not really clever. struct fw_loading { ... } __fw_loading_*() fw_loading_*() Would that make more sense? firmware_loading_ as

Re: [RFC v0 4/8] Input: goodix: use firmware_stat instead of completion

On Thu, 2016-07-28 at 13:59 +0200, Daniel Wagner wrote: > On 07/28/2016 01:22 PM, Bastien Nocera wrote: > > On Thu, 2016-07-28 at 09:55 +0200, Daniel Wagner wrote: > > > From: Daniel Wagner > > > > > > Loading firmware is an operation many drivers implement in > > >

Re: [RFC v0 4/8] Input: goodix: use firmware_stat instead of completion

On 07/28/2016 01:22 PM, Bastien Nocera wrote: On Thu, 2016-07-28 at 09:55 +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

Re: [PATCH 2/3] staging: wilc1000: One function call less in mac_ioctl() after error detection

Hi Marcus, On Mon, Jul 25, 2016 at 6:22 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 24 Jul 2016 21:15:23 +0200 > > The kfree() function was called in two cases by the mac_ioctl() function > during error handling

Aw: Re: staging: wilc1000: Reduce scope for a few variables in mac_ioctl()

> Gesendet: Dienstag, 26. Juli 2016 um 08:25 Uhr > Von: "SF Markus Elfring" > > >> - if (strncasecmp(buff, "RSSI", length) == 0) { > >> + if (strncasecmp(buff, "RSSI", 0) == 0) { > >> + s8 rssi; > >> + >

Re: ath10k: Remove driver log suggesting QCA9887 support is experimental

Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Support for QCA9887 is no longer experimental and if there are any issues > we need to address them > > Signed-off-by: Mohammed Shafi Shajakhan

Re: ath10k: fix get rx_status from htt context

Ashok Raj Nagarajan wrote: > On handling amsdu on rx path, get the rx_status from htt context. Without this > fix, we are seeing warnings when running DBDC traffic like this. > > WARNING: CPU: 0 PID: 0 at net/mac80211/rx.c:4105 ieee80211_rx_napi+0x88/0x7d8 >

[RFC v0 2/8] selftests: firmware: do not clutter output

From: Daniel Wagner Some of the test are supposed to fail but we get a few ouptput lines: ./fw_filesystem.sh: line 51: printf: write error: Invalid argument ./fw_filesystem.sh: line 56: printf: write error: No such device ./fw_filesystem.sh: line 62: echo: write

[RFC v0 5/8] ath9k_htc: use firmware_stat instead of completion

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 API which is used also by the firmware_class loader. Apart of

[RFC v0 8/8] iwl4965: use firmware_stat instead of completion

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 API which is used also by the firmware_class loader. Apart of

[RFC v0 6/8] remoteproc: use firmware_stat instead of completion

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 API which is used also by the firmware_class loader. Apart of

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

From: Daniel Wagner Factor out the firmware loading synchronization code in order to allow drivers to reuse it. This also documents more clearly what is happening. This is especial useful the drivers which will be converted afterwards. Not everyone has to come with

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

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 API which is used also by the firmware_class loader. Apart of

[RFC v0 0/8] Reuse firmware loader helpers

From: Daniel Wagner Hi, While reviewing all the complete_all() users, I realized there is recouring pattern how the completion API is used to synchronize the stages of the firmware loading. Since firmware_class.c contains a fairly complete implemetation for synching

[RFC v0 1/8] selftests: firmware: do not abort test too early

From: Daniel Wagner When running the test script you will get: kselftest/firmware/fw_userhelper.sh: line 69: echo: write error: Resource temporarily unavailable and stops right there. Because the script runs with the '-e' option which will stop the script at any

[RFC v0 4/8] Input: goodix: use firmware_stat instead of completion

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 API which is used also by the firmware_class loader. Apart of

rfkill bound to a switch

Hi there, Since laptops typically have a toggle button for killing and enabled wifi, how does one supposed to bind rfkill like a toggle? I.e. knowing which state you are in so you can call {block,unblock} accordingly? Parsing event or list output seems non-trivial. Kind regards, -- To