* [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: Arvind Yadav @ 2016-07-31 11:18 UTC (permalink / raw)
To: zajec5, leoli
Cc: qiang.zhao, scottwood, viresh.kumar, akpm, linux-wireless, netdev,
linuxppc-dev, linux, arnd, davem, David.Laight, Arvind Yadav
IS_ERR_VALUE() assumes that parameter is an unsigned long.
It can not be used to check if 'unsigned int' is passed insted.
Which tends to reflect an error.
In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
value is zero extended to 64 bits.
Value of (unsigned int)-4095 is always less than value of
(unsigned long)-4095.
Now We are taking only first 32 bit for error checking rest of the 32 bit
we ignore such that we get appropriate comparison on 64bit system as well.
First 32bit of Value of (unsigned int)-4095 and (unsigned long)-4095 will
be equal.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
include/linux/err.h | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/linux/err.h b/include/linux/err.h
index 1e35588..c2a2789 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -18,7 +18,17 @@
#ifndef __ASSEMBLY__
-#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
+#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
+
+static inline int is_error_check(unsigned long error)
+{
+ unsigned int first32bit = (error & 0xFFFFFFFF);
+
+ if (first32bit >= (unsigned int)-MAX_ERRNO)
+ return 1;
+ else
+ return 0;
+}
static inline void * __must_check ERR_PTR(long error)
{
--
1.9.1
^ permalink raw reply related
* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: Scott Wood @ 2016-08-01 16:55 UTC (permalink / raw)
To: Arnd Bergmann, linuxppc-dev@lists.ozlabs.org
Cc: Arvind Yadav, zajec5@gmail.com, leoli@freescale.com,
qiang.zhao@freescale.com, viresh.kumar@linaro.org,
linux-wireless@vger.kernel.org, David.Laight@aculab.com,
netdev@vger.kernel.org, scottwood@freescale.com,
akpm@linux-foundation.org, davem@davemloft.net,
linux@roeck-us.net
In-Reply-To: <1956647.cOmaJREgOE@wuerfel>
On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
> On Sunday, July 31, 2016 4:48:44 PM CEST Arvind Yadav wrote:
>> IS_ERR_VALUE() assumes that parameter is an unsigned long.
>> It can not be used to check if 'unsigned int' is passed insted.
>> Which tends to reflect an error.
>>
>> In 64bit architectures sizeof (int) == 4 && sizeof (long) == 8.
>> IS_ERR_VALUE(x) is ((x) >= (unsigned long)-4095).
>>
>> IS_ERR_VALUE() of 'unsigned int' is always false because the 32bit
>> value is zero extended to 64 bits.
>>
>> Value of (unsigned int)-4095 is always less than value of
>> (unsigned long)-4095.
>>
>> Now We are taking only first 32 bit for error checking rest of the 32 bit
>> we ignore such that we get appropriate comparison on 64bit system as well.
>
> This is completely wrong: if you have a valid 64-bit pointer like
> 0x00001234ffffff00, this will be interpreted as an error now.
>
>> First 32bit of Value of (unsigned int)-4095 and (unsigned long)-4095 will
>> be equal.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>> ---
>> include/linux/err.h | 12 +++++++++++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/err.h b/include/linux/err.h
>> index 1e35588..c2a2789 100644
>> --- a/include/linux/err.h
>> +++ b/include/linux/err.h
>> @@ -18,7 +18,17 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
>> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
>> +
>> +static inline int is_error_check(unsigned long error)
>
> Please leave the existing macro alone. I think you were looking for
> something specific to the return code of qe_muram_alloc() function,
> so please add a helper in that subsystem if you need it, not in
> the generic header files.
qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
problem is certain callers that store the return value in a u32. Why
not just fix those callers to store it in unsigned long (at least until
error checking is done)?
-Scott
^ permalink raw reply
* [PATCH] drivers: wilc1000: remove references to semaphores
From: Joshua Houghton @ 2016-08-01 19:17 UTC (permalink / raw)
To: Johnny Kim, linux-wireless
Cc: Austin Shin, Chris Park, Tony Cho, Glen Lee, Leo Kim, devel,
linux-kernel, Greg Kroah-Hartman
* Update the comments that refer to semaphores
* Remove redundant includes to semphore.h
Signed-off-by: Joshua Houghton <josh@awful.name>
---
drivers/staging/wilc1000/TODO | 1 -
drivers/staging/wilc1000/linux_wlan.c | 1 -
drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +-
drivers/staging/wilc1000/wilc_wlan.h | 2 +-
drivers/staging/wilc1000/wilc_wlan_if.h | 1 -
5 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/wilc1000/TODO b/drivers/staging/wilc1000/TODO
index ec93b2e..ae61b55 100644
--- a/drivers/staging/wilc1000/TODO
+++ b/drivers/staging/wilc1000/TODO
@@ -3,7 +3,6 @@ TODO:
- remove OS wrapper functions
- remove custom debug and tracing functions
- rework comments and function headers(also coding style)
-- replace all semaphores with mutexes or completions
- Move handling for each individual members of 'union message_body' out
into a separate 'struct work_struct' and completely remove the multiplexer
that is currently part of host_if_work(), allowing movement of the
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index 3a66255..315ed2e 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -21,7 +21,6 @@
#include <linux/kernel.h>
#include <linux/skbuff.h>
#include <linux/mutex.h>
-#include <linux/semaphore.h>
#include <linux/completion.h>
static int dev_state_ev_handler(struct notifier_block *this,
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 5cc6a82..ec6b167 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -131,7 +131,7 @@ struct wilc_priv {
struct wilc_wfi_key *wilc_gtk[MAX_NUM_STA];
struct wilc_wfi_key *wilc_ptk[MAX_NUM_STA];
u8 wilc_groupkey;
- /* semaphores */
+ /* mutexes */
struct mutex scan_req_lock;
/* */
bool gbAutoRateAdjusted;
diff --git a/drivers/staging/wilc1000/wilc_wlan.h b/drivers/staging/wilc1000/wilc_wlan.h
index 30e5312..739900e 100644
--- a/drivers/staging/wilc1000/wilc_wlan.h
+++ b/drivers/staging/wilc1000/wilc_wlan.h
@@ -192,7 +192,7 @@
#define ENABLE_RX_VMM (SEL_VMM_TBL1 | EN_VMM)
#define ENABLE_TX_VMM (SEL_VMM_TBL0 | EN_VMM)
-/*time for expiring the semaphores of cfg packets*/
+/*time for expiring the completion of cfg packets*/
#define CFG_PKTS_TIMEOUT 2000
/********************************************
*
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h b/drivers/staging/wilc1000/wilc_wlan_if.h
index 410bfc0..439ac6f 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -10,7 +10,6 @@
#ifndef WILC_WLAN_IF_H
#define WILC_WLAN_IF_H
-#include <linux/semaphore.h>
#include <linux/netdevice.h>
/********************************************
--
2.9.2
^ permalink raw reply related
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-01 19:44 UTC (permalink / raw)
To: Daniel Wagner
Cc: Dmitry Torokhov, Luis R. Rodriguez, Arend van Spriel,
Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <37a3cd66-262e-ffbe-ea7a-a6d5b1ca1c8b@bmw-carit.de>
On Mon, Aug 01, 2016 at 02:26:04PM +0200, Daniel Wagner wrote:
> On 07/31/2016 09:23 AM, Dmitry Torokhov wrote:
> >On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez" <mcgrof@kernel.org> wrote:
> >>On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel wrote:
> >>>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:
>
> >>>+ Luis (again) ;-)
>
> That was not on purpose :) My attempt to keep the Cc list a bit
> shorter was a failure.
>
> >>>>>>Do not quite like it... I'd rather asynchronous request give out
> >>>>>>firmware status pointer that could be used later on.
> >>>
> >>>Excellent. Why not get rid of the callback function as well and have
> >>>fw_loading_wait() return result (0 = firmware available, < 0 = fail).
> >>>Just to confirm, you are proposing a new API function next to
> >>>request_firmware_nowait(), right?
> >>
> >>If proposing new firmware_class patches please bounce / Cc me, I've
> >>recently asked for me to be added to MAINTAINERS so I get these
> >>e-mails as I'm working on a new flexible API which would allow us
> >>to extend the firmware API without having to care about the old
> >>stupid usermode helper at all.
>
> These patches here are a first attempt to clean up a bit of the code
> around the completion API. As Dmitry correctly pointed out, it makes
> more sense to go bit further and make the async loading a bit more
> convenient for the drivers.
>
> >I am not sure why we started calling usermode helper "stupid". We
> >only had to implement direct kernel firmware loading because udev/stsremd
> >folks had "interesting" ideas how events should be handled; but having
> >userspace to feed us data is not stupid.
>
> I was ignorant on all the nasty details around the firmware loading.
> If I parse Luis' patches correctly they introduce an API which calls
> kernel_read_file_from_path() asynchronously:
>
> sysdata_file_request_async(..., &cookie)
> *coookie = async_schedule_domain(request_sysdata_file_work_func(), ..)
>
> request_sysdata_file_work_fun()
> _sysdata_file_request()
> fw_get_filesystem_firmware()
> kernel_read_file_from_path()
>
> sysdata_synchronize_request(&cookie);
>
> Doesn't look like what your asking for.
No, but its also a generic kernel read issue as I noted in my last
reply.
> >If we want to overhaul firmware loading support we need to figure
> >out how to support case when a driver want to [asynchronously] request
> >firmware/config/blob and the rest of the system is not ready. Even if we
> >want kernel to do read/load the data we need userspace to tell kernel
> >when firmware partition is available, until then the kernel should not
> >fail the request.
>
> I gather from Luis' blog post and comments that he is on the quest
> on removing userspace support completely.
No, I explained in my last proposed documentation patch series that we cannot
get rid of the usermode helper. Its not well understood why so I explained and
documented why. Best we can do is compartamentalize its uses.
The sysdata API's main goal rather is to provide a flexible API first,
compartamentalizing the usermode helper was secondary. But now it seems
I may just also add devm support too to help simplify code further.
What Dmitry notes is an existential issue with kernel_read_file_from_path()
and we need a common solution for it.
> Maybe this attempt here could be a step before. Step 1 would be
> changing request_firmware_nowait() to request_firmware_async so
> drivers don't have to come up with their own sync primitives, e.g.
>
> cookie = request_firmware_async()
> fw_load_wait(cookie)
That's one of the features already part of async mechanism of the sysdata API :)
Luis
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-01 19:56 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Luis R. Rodriguez, Arend van Spriel, Daniel Wagner,
Dmitry Torokhov, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Julia Lawall, Mimi Zohar, Andy Lutomirski, David Woodhouse,
David Howells, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <20160801171951.GC13516@tuxbot>
On Mon, Aug 01, 2016 at 10:19:51AM -0700, Bjorn Andersson wrote:
> On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote:
>
> > On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel 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:
> > > >>
> > > >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
> > > >>>> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
> > > >>>>
> > > >> [..]
> > > >>>
> > > >>> Do not quite like it... I'd rather asynchronous request give out a
> > > >>> firmware status pointer that could be used later on.
> > >
> > > Excellent. Why not get rid of the callback function as well and have
> > > fw_loading_wait() return result (0 = firmware available, < 0 = fail).
> > > Just to confirm, you are proposing a new API function next to
> > > request_firmware_nowait(), right?
> >
> > If proposing new firmware_class patches please bounce / Cc me, I've
> > recently asked for me to be added to MAINTAINERS so I get these
> > e-mails as I'm working on a new flexible API which would allow us
> > to extend the firmware API without having to care about the old
> > stupid usermode helper at all.
> >
>
> In the remoteproc world there are several systems where we see 100+MB of
> firmware being loaded. It's unfeasible to have these files in an
> initramfs, so we need a way to indicate to the kernel that the
> second/primary (or a dedicated firmware partition) is mounted.
>
> We're currently loading these files with request_firmware_nowait(), so
> either one can either use kernel modules or the user-helper fallback to
> delay the loading until the files are available. (I don't like to
> enforce the usage of kernel modules)
Now that the firmware API is sharing the same API call to read files
the existential issue of the file is not unique issue of firmware,
but also to any other caller of it.
> I'm open to alternative ways of having firmware loading wait on
> secondary filesystems to be mounted, but have not yet tried to tackle
> this problem. I do believe something that waits and retries the firmware
> load as additional file systems gets mounted would be prettier than
> forcing user space to tell us it's time to move on.
Agreed. We simply have not addressed this problem yet. Let's discuss a
possible solution on the other reply thread I provided with more details
to Dmitry.
> Due to the size of these firmware files we release the firmware as soon
> as we have copied the content into the appropriate memory segments, so
> we're not utilizing the caching mechanisms of the current fw loader.
BTW my goal with the sysdata API is to automatically free this for you too :)
Luis
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-01 19:36 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Luis R. Rodriguez, Arend van Spriel, Daniel Wagner,
Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <C528E404-0CA5-46B4-B551-B1D4B58BC053@gmail.com>
On Sun, Jul 31, 2016 at 12:23:09AM -0700, Dmitry Torokhov wrote:
> On July 30, 2016 9:58:17 AM PDT, "Luis R. Rodriguez" <mcgrof@kernel.org> wrote:
> >On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel 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:
> >> >>
> >> >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
> >> >>>> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
> >> >>>>
> >> >> [..]
> >> >>>
> >> >>> Do not quite like it... I'd rather asynchronous request give out
> >a
> >> >>> firmware status pointer that could be used later on.
> >>
> >> Excellent. Why not get rid of the callback function as well and have
> >> fw_loading_wait() return result (0 = firmware available, < 0 = fail).
> >> Just to confirm, you are proposing a new API function next to
> >> request_firmware_nowait(), right?
> >
> >If proposing new firmware_class patches please bounce / Cc me, I've
> >recently asked for me to be added to MAINTAINERS so I get these
> >e-mails as I'm working on a new flexible API which would allow us
> >to extend the firmware API without having to care about the old
> >stupid usermode helper at all.
>
> I am not sure why we started calling usermode helper "stupid".
OK Fair, how systemd implemented kmod timeout for the usermode helper
was stupid and it affected tons of systems.
> We only had to
> implement direct kernel firmware loading because udev/stsremd folks had
> "interesting" ideas how events should be handled; but having userspace to
> feed us data is not stupid.
It really should just be an option. The problem was the collateral due to the
way it was handled in userspace.
> If we want to overhaul firmware loading support we need to figure out how to
> support case when a driver want to [asynchronously] request
> firmware/config/blob and the rest of the system is not ready.
There's a lot of issues. So let's break them down.
1) First the sysdata API came about to help avoid the required set of collateral
evolutions whenever the firmware API was expanded. A new argument added meant
requiring to modify all drivers with the new argument, or a new exported
symbol. The sysdata API makes the API flexible, enabling extensions by just
expanding on the descriptor passed. The few features I've added to sysdata
(like avoiding drivers having to declare their own completions, waits) are
just small enhancements, but it seems now supporting devm may be desirable
as well.
2) The usermode helper cannot be removed, however we can compartamentalize it.
The sysdata API aims at helping with that, it doesn't touch it. There are
only 2 explicit users of the usermode helper now in the kernel. If there are
further users that really want it, I'd like to hear about them.
3) The firmware API having its own kernel read thing was fine but there were
other places in the kernel doing the same, this begged sharing that code
and also allowing then two LSM hooks to take care of handling doing whatever
with a kernel read, a pre-read hook and post-read hook. Mimi completed this
work and we now have the firmware API using kernel_read_file_from_path().
4) The asynchronous firmware loading issue you describe above is just *one*
issue, but it becomes more of an generic issue if you consider 3) above...
because naturally there could potentially be other users of kernel_read_file()
or kernel_read_file_from_path() and whereby a race also can happen. We may
decide that this is up to the subsystem/user to figure out. If that's the
case lets discuss that. It however occurs to me that it could just be as
simple as adding another fs/exec.c helper like kernel_read_file_from_path_wait()
which passes a completion and fs/exec.c just signals back when its ready.
If we have this both the old firmware_class and new sysdata API could benefit
from this behind the scenes -- no new API extension would be needed, this
would just be a firmware_class fix to use a more deterministic kernel
read API.
> Even if we want kernel to do read/load the data we need userspace to tell
> kernel when firmware partition is available, until then the kernel should not
> fail the request.
pivot_root() is possible as well, so exactly when the *real* partition is
ready is very system specific -- best I think we can do is perhaps just
see when the *first* file path becomes available and signal back. Problem
with this is we would still need a way to know -- *everything is ready*
as a limit condition for waiting.
Luis
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Dmitry Torokhov @ 2016-08-01 21:34 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Luis R. Rodriguez, Arend van Spriel, Daniel Wagner, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <20160801171951.GC13516@tuxbot>
On Mon, Aug 01, 2016 at 10:19:51AM -0700, Bjorn Andersson wrote:
> On Sat 30 Jul 09:58 PDT 2016, Luis R. Rodriguez wrote:
>
> > On Sat, Jul 30, 2016 at 02:42:41PM +0200, Arend van Spriel 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:
> > > >>
> > > >>> On Thu, Jul 28, 2016 at 09:55:11AM +0200, Daniel Wagner wrote:
> > > >>>> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
> > > >>>>
> > > >> [..]
> > > >>>
> > > >>> Do not quite like it... I'd rather asynchronous request give out a
> > > >>> firmware status pointer that could be used later on.
> > >
> > > Excellent. Why not get rid of the callback function as well and have
> > > fw_loading_wait() return result (0 = firmware available, < 0 = fail).
> > > Just to confirm, you are proposing a new API function next to
> > > request_firmware_nowait(), right?
> >
> > If proposing new firmware_class patches please bounce / Cc me, I've
> > recently asked for me to be added to MAINTAINERS so I get these
> > e-mails as I'm working on a new flexible API which would allow us
> > to extend the firmware API without having to care about the old
> > stupid usermode helper at all.
> >
>
> In the remoteproc world there are several systems where we see 100+MB of
> firmware being loaded. It's unfeasible to have these files in an
> initramfs, so we need a way to indicate to the kernel that the
> second/primary (or a dedicated firmware partition) is mounted.
>
> We're currently loading these files with request_firmware_nowait(), so
> either one can either use kernel modules or the user-helper fallback to
> delay the loading until the files are available. (I don't like to
> enforce the usage of kernel modules)
>
> I'm open to alternative ways of having firmware loading wait on
> secondary filesystems to be mounted, but have not yet tried to tackle
> this problem. I do believe something that waits and retries the firmware
> load as additional file systems gets mounted would be prettier than
> forcing user space to tell us it's time to move on.
Hmm, but when do you stop? How do you know that you are not going to get
yet another fs mounted and that one will finally have the firmware you
are looking for? The kernel does now, but distribution/product
integrator does. That is why I think the most reliable way is to see if
firmware is built-in, otherwise wait and let userspace do its thing.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Masashi Honma @ 2016-08-02 2:59 UTC (permalink / raw)
To: Johannes Berg
Cc: Yaniv Machani, linux-kernel, Meirav Kama, David S. Miller,
linux-wireless, netdev
In-Reply-To: <75fef3ce-41a6-5845-e9be-d7ff052a07da@gmail.com>
> On 2016年08月01日 19:03, Johannes Berg wrote:
>>
>> But why is that behaviour *correct*? We still support 40 MHz bandwidth
>> things, we just don't use them if we disable HT40.
Or do you mean difference between "hardware capability" and "software
capability" ?
Do you think IEEE80211_HT_CAP_SUP_WIDTH_20_40 bit should be 1 if the
hardware capable of HT40 even though HT40 is disabled by
wpa_supplicant/hostapd ?
I have tested with hostapd. I compared these 2 configfiles.
hostapd0.conf
ht_capab=[HT40-]
hostapd1.conf
#ht_capab=[HT40-]
The IEEE80211_HT_CAP_SUP_WIDTH_20_40 bit in beacon was below.
hostapd0.conf
IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 1
hostapd1.conf
IEEE80211_HT_CAP_SUP_WIDTH_20_40 = 0
So I think the bit should be zero if disabled also for mesh peer.
Masashi Honma.
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Daniel Wagner @ 2016-08-02 5:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dmitry Torokhov, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input, linux-kselftest,
linux-wireless, linux-kernel
In-Reply-To: <20160801194408.GZ3296@wotan.suse.de>
Hi Luis,
>> I was ignorant on all the nasty details around the firmware loading.
>> If I parse Luis' patches correctly they introduce an API which calls
>> kernel_read_file_from_path() asynchronously:
>>
>> sysdata_file_request_async(..., &cookie)
>> *coookie = async_schedule_domain(request_sysdata_file_work_func(), ..)
>>
>> request_sysdata_file_work_fun()
>> _sysdata_file_request()
>> fw_get_filesystem_firmware()
>> kernel_read_file_from_path()
>>
>> sysdata_synchronize_request(&cookie);
>>
>> Doesn't look like what your asking for.
>
> No, but its also a generic kernel read issue as I noted in my last
> reply.
Okay, got it.
>>> If we want to overhaul firmware loading support we need to figure
>>> out how to support case when a driver want to [asynchronously] request
>>> firmware/config/blob and the rest of the system is not ready. Even if we
>>> want kernel to do read/load the data we need userspace to tell kernel
>>> when firmware partition is available, until then the kernel should not
>>> fail the request.
>>
>> I gather from Luis' blog post and comments that he is on the quest
>> on removing userspace support completely.
>
> No, I explained in my last proposed documentation patch series that we cannot
> get rid of the usermode helper.
I stand corrected.
> Its not well understood why so I explained and documented why.
Obviously, I got lost somewhere there :)
> Best we can do is compartamentalize its uses.
Sounds like a plan.
> The sysdata API's main goal rather is to provide a flexible API first,
> compartamentalizing the usermode helper was secondary. But now it seems
> I may just also add devm support too to help simplify code further.
I missed the point that you plan to add usermode helper support to the
sysdata API.
> What Dmitry notes is an existential issue with kernel_read_file_from_path()
> and we need a common solution for it.
Understood. I guess best thing to keep that discussion in the other
subthread.
>> Maybe this attempt here could be a step before. Step 1 would be
>> changing request_firmware_nowait() to request_firmware_async so
>> drivers don't have to come up with their own sync primitives, e.g.
>>
>> cookie = request_firmware_async()
>> fw_load_wait(cookie)
>
> That's one of the features already part of async mechanism of the sysdata API :)
Yes, I realized that too :)
cheers,
daniel
Thanks for the feedback.
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-02 6:34 UTC (permalink / raw)
To: Daniel Wagner
Cc: Luis R. Rodriguez, Dmitry Torokhov, Arend van Spriel,
Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <0f9350fa-e8b5-9d64-b2d3-afda5e5f6bbf@bmw-carit.de>
On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote:
> >The sysdata API's main goal rather is to provide a flexible API first,
> >compartamentalizing the usermode helper was secondary. But now it seems
> >I may just also add devm support too to help simplify code further.
>
> I missed the point that you plan to add usermode helper support to
> the sysdata API.
I had no such plans, when I have asked folks so far about "hey are you
really in need for it, OK what for? " and "what extended uses do you
envision?" so I far I have not gotten any replies at all. So -- instead
sysdata currently ignores it.
Luis
^ permalink raw reply
* [Bug][AR9285] WiFi LED stops working after suspend/hibernate cycle with 4.7.0 kernel
From: Ilya Tumaykin @ 2016-08-02 5:48 UTC (permalink / raw)
To: QCA ath9k Development; +Cc: linux-wireless, ath9k-devel
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
Hello.
After kernel upgrade from 4.6.4 to 4.7.0 WiFi LED stops working after
suspend/hibernate cycle. LED works properly right after (re)boot. LED worked
properly after suspend/hibernate cycle with 4.6.4, thus it's a regression.
My hardware is "Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express)
[168c:002b] (rev 01)", my OS is Gentoo amd64, my ath9k modprobe configuration
is "options ath9k blink=0 btcoex_enable=1 bt_ant_diversity=1 ps_enable=1".
I've attached my kernel configuration and "lspci -vvv -nn -k" output.
Please let me know if you need more info.
Steps to reproduce:
1. Boot computer and connect to WiFi network.
2. Suspend/hibernate computer.
3. Resume/thaw computer.
4. Connect to WiFi network again.
Actual results:
WiFi LED is off.
Expected results:
WiFi LED is on.
Please fix.
--
Best regards.
Ilya Tumaykin.
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 21801 bytes --]
[-- Attachment #3: lspci --]
[-- Type: text/plain, Size: 24449 bytes --]
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02)
Subsystem: Acer Incorporated [ALI] Core Processor DRAM Controller [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Core Processor Integrated Graphics Controller [1025:040e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 24
Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 3050 [size=8]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 4181
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06)
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset HECI Controller [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 25
Region 0: Memory at d4406100 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41a2
Kernel driver in use: mei_me
00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05) (prog-if 20 [EHCI])
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [1025:040e]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d4405c00 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05)
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset High Definition Audio [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 27
Region 0: Memory at d4400000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41b2
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
Capabilities: [100 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=1 ArbSelect=Fixed TC/VC=02
Status: NegoPending- InProgress-
Capabilities: [130 v1] Root Complex Link
Desc: PortNumber=0f ComponentID=00 EltType=Config
Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+
Addr: 00000000fed1c000
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: d3400000-d43fffff
Prefetchable memory behind bridge: 00000000d0400000-00000000d13fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset PCI Express Root Port 1 [1025:040e]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 16
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: d2400000-d33fffff
Prefetchable memory behind bridge: 00000000d1400000-00000000d23fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #1, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset PCI Express Root Port 2 [1025:040e]
Capabilities: [a0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
00:1d.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 05) (prog-if 20 [EHCI])
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at d4405800 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ehci-pci
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev a5) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: fff00000-000fffff
Prefetchable memory behind bridge: 00000000fff00000-00000000000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [50] Subsystem: Acer Incorporated [ALI] 82801 Mobile PCI Bridge [1025:040e]
00:1f.0 ISA bridge [0601]: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller [8086:3b09] (rev 05)
Subsystem: Acer Incorporated [ALI] Mobile 5 Series Chipset LPC Interface Controller [1025:040e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=10 <?>
Kernel driver in use: lpc_ich
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller [8086:3b29] (rev 05) (prog-if 01 [AHCI 1.0])
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset 4 port SATA AHCI Controller [1025:040e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 26
Region 0: I/O ports at 3048 [size=8]
Region 1: I/O ports at 305c [size=4]
Region 2: I/O ports at 3040 [size=8]
Region 3: I/O ports at 3058 [size=4]
Region 4: I/O ports at 3020 [size=32]
Region 5: Memory at d4405000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c Data: 41b1
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Capabilities: [b0] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: ahci
00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 05)
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset SMBus Controller [1025:040e]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin C routed to IRQ 19
Region 0: Memory at d4406000 (64-bit, non-prefetchable) [size=256]
Region 4: I/O ports at 3000 [size=32]
Kernel driver in use: i801_smbus
00:1f.6 Signal processing controller [1180]: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem [8086:3b32] (rev 05)
Subsystem: Acer Incorporated [ALI] 5 Series/3400 Series Chipset Thermal Subsystem [1025:040e]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 21
Region 0: Memory at d4404000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Kernel driver in use: intel ips
01:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8151 v1.0 Gigabit Ethernet [1969:1073] (rev c0)
Subsystem: Acer Incorporated [ALI] AR8151 v1.0 Gigabit Ethernet [1025:040e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 28
Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=256K]
Region 2: I/O ports at 2000 [size=128]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0f00c Data: 41e2
Capabilities: [58] Express (v1) Endpoint, MSI 00
DevCap: MaxPayload 4096 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag- AttnBtn+ AttnInd+ PwrInd+ RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [6c] Vital Product Data
Not readable
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt+ UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP- SDES+ TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP+ BadDLLP+ Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 0f, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [180 v1] Device Serial Number ff-02-b2-a4-20-6a-8a-ff
Kernel driver in use: atl1c
Kernel modules: atl1c
02:00.0 Network controller [0280]: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) [168c:002b] (rev 01)
Subsystem: Foxconn International, Inc. AR9285 Wireless Network Adapter (PCI-Express) [105b:e016]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at d2400000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [60] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-15-17-ff-ff-24-14-12
Capabilities: [170 v1] Power Budgeting <?>
Kernel driver in use: ath9k
Kernel modules: ath9k
ff:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers [8086:2c62] (rev 05)
Subsystem: Acer Incorporated [ALI] Core Processor QuickPath Architecture Generic Non-core Registers [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
ff:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2d01] (rev 05)
Subsystem: Acer Incorporated [ALI] Core Processor QuickPath Architecture System Address Decoder [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
ff:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2d10] (rev 05)
Subsystem: Acer Incorporated [ALI] Core Processor QPI Link 0 [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
ff:02.1 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor QPI Physical 0 [8086:2d11] (rev 05)
Subsystem: Acer Incorporated [ALI] 1st Generation Core i3/5/7 Processor QPI Physical 0 [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
ff:02.2 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved [8086:2d12] (rev 05)
Subsystem: Acer Incorporated [ALI] 1st Generation Core i3/5/7 Processor Reserved [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
ff:02.3 Host bridge [0600]: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved [8086:2d13] (rev 05)
Subsystem: Acer Incorporated [ALI] 1st Generation Core i3/5/7 Processor Reserved [1025:040e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Daniel Wagner @ 2016-08-02 6:53 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Dmitry Torokhov, Arend van Spriel, Bjorn Andersson, Daniel Wagner,
Bastien Nocera, Greg Kroah-Hartman, Johannes Berg, Kalle Valo,
Ohad Ben-Cohen, Mimi Zohar, David Howells, Andy Lutomirski,
David Woodhouse, Julia Lawall, linux-input, linux-kselftest,
linux-wireless, linux-kernel
In-Reply-To: <20160802063419.GG3296@wotan.suse.de>
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 rather is to provide a flexible API first,
>>> compartamentalizing the usermode helper was secondary. But now it seems
>>> I may just also add devm support too to help simplify code further.
>>
>> I missed the point that you plan to add usermode helper support to
>> the sysdata API.
>
> I had no such plans, when I have asked folks so far about "hey are you
> really in need for it, OK what for? " and "what extended uses do you
> envision?" so I far I have not gotten any replies at all. So -- instead
> sysdata currently ignores it.
So you argue for the remoteproc use case with 100+ MB firmware that if
there is a way to load after pivot_root() (or other additional firmware
partition shows up) then there is no need at all for usermode helper?
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Johannes Berg @ 2016-08-02 7:27 UTC (permalink / raw)
To: Masashi Honma
Cc: Yaniv Machani, linux-kernel, Meirav Kama, David S. Miller,
linux-wireless, netdev
In-Reply-To: <1c2d3cfc-b7fd-c8fd-4f74-14dd3aa3076e@gmail.com>
On Tue, 2016-08-02 at 11:59 +0900, Masashi Honma wrote:
> >
> > On 2016年08月01日 19:03, Johannes Berg wrote:
> > >
> > > But why is that behaviour *correct*? We still support 40 MHz
> > > bandwidth
> > > things, we just don't use them if we disable HT40.
>
> Or do you mean difference between "hardware capability" and "software
> capability" ?
> Do you think IEEE80211_HT_CAP_SUP_WIDTH_20_40 bit should be 1 if the
> hardware capable of HT40 even though HT40 is disabled by
> wpa_supplicant/hostapd ?
I basically think that the CAP_SUP_WIDTH_20_40 bit shouldn't matter at
all, so it's not clear to me why there's so much talk about it.
After all, if 40 MHz isn't actually *used* as indicated by the HT
operation (rather than HT capability) IE, then the fact that the device
may or may not support 40 MHz is pretty much irrelevant.
> I have tested with hostapd. I compared these 2 configfiles.
>
> hostapd0.conf
> ht_capab=[HT40-]
> hostapd1.conf
> #ht_capab=[HT40-]
>
This explicitly configures *HT capability* though - that's even the
name of the parameter. If you enable HT40 in the capability, the
resulting BSS might still not actually *use* 40 MHz bandwidth, as
required by overlapping BSS detection.
In this patch, they're taking one thing (current HT channel width
configuration) and applying it to another thing (HT capability), and
then even selling it as a bugfix - which I simply cannot understand.
The HT capability shouldn't matter at all, if HT operation is correct.
johannes
^ permalink raw reply
* Re: [PATCH] nl80211: Expand max value of NL80211_MESHCONF_HT_OPMODE command
From: Johannes Berg @ 2016-08-02 7:43 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <1468927556-4703-1-git-send-email-masashi.honma@gmail.com>
On Tue, 2016-07-19 at 20:25 +0900, Masashi Honma wrote:
> Previously, the max value of NL80211_MESHCONF_HT_OPMODE was 16.
> But it causes EINVAL when IEEE80211_HT_OP_MODE_PROTECTION_NONHT_MIXED
> and IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT bit is enabled.
> So this patch expands the max value.
>
> Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
> ---
> net/wireless/nl80211.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 46417f9..8a00e50 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -5471,7 +5471,10 @@ do {
> \
> FILL_IN_MESH_PARAM_IF_SET(tb, cfg, rssi_threshold, -255, 0,
> mask,
> NL80211_MESHCONF_RSSI_THRESHOLD,
> nl80211_check_s32);
> - FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0, 16,
> + FILL_IN_MESH_PARAM_IF_SET(tb, cfg, ht_opmode, 0,
> + IEEE80211_HT_OP_MODE_PROTECTION |
> + IEEE80211_HT_OP_MODE_NON_GF_STA_PRSNT |
> + IEEE80211_HT_OP_MODE_NON_HT_STA_PRSNT,
> mask, NL80211_MESHCONF_HT_OPMODE,
> nl80211_check_u16);
>
Hmm. So first of all, it looks like the old value was wrong because 16
would have been an allowed value, which doesn't make sense - 15 was
likely the maximum that should've been allowed?
You're now changing it to 23, which makes some sense, but is kinda
strange. It allows setting the unused bit 0x8 by itself or in
combination with any protection and/or the NON_GF bit, but not in
combination with the NON_HT bit.
It seems that perhaps this should rather check the value against a
bitmap of allowed bits, which would be exactly the ones you add in this
patch?
johannes
^ permalink raw reply
* Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.
From: Arnd Bergmann @ 2016-08-02 7:45 UTC (permalink / raw)
To: linuxppc-dev
Cc: Scott Wood, qiang.zhao@freescale.com, viresh.kumar@linaro.org,
zajec5@gmail.com, linux-wireless@vger.kernel.org,
David.Laight@aculab.com, netdev@vger.kernel.org,
scottwood@freescale.com, Arvind Yadav, akpm@linux-foundation.org,
davem@davemloft.net, linux@roeck-us.net
In-Reply-To: <DB5PR0401MB19280ACA87C7F5EE2822D5FB91040@DB5PR0401MB1928.eurprd04.prod.outlook.com>
On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote:
> On 08/01/2016 02:02 AM, Arnd Bergmann wrote:
> >> diff --git a/include/linux/err.h b/include/linux/err.h
> >> index 1e35588..c2a2789 100644
> >> --- a/include/linux/err.h
> >> +++ b/include/linux/err.h
> >> @@ -18,7 +18,17 @@
> >>
> >> #ifndef __ASSEMBLY__
> >>
> >> -#define IS_ERR_VALUE(x) unlikely((unsigned long)(void *)(x) >= (unsigned long)-MAX_ERRNO)
> >> +#define IS_ERR_VALUE(x) unlikely(is_error_check(x))
> >> +
> >> +static inline int is_error_check(unsigned long error)
> >
> > Please leave the existing macro alone. I think you were looking for
> > something specific to the return code of qe_muram_alloc() function,
> > so please add a helper in that subsystem if you need it, not in
> > the generic header files.
>
> qe_muram_alloc (a.k.a. cpm_muram_alloc) returns unsigned long. The
> problem is certain callers that store the return value in a u32. Why
> not just fix those callers to store it in unsigned long (at least until
> error checking is done)?
>
Yes, that would also address another problem with code like
kfree((void *)ugeth->tx_bd_ring_offset[i]);
which is not 64-bit safe when tx_bd_ring_offset is a 32-bit value
that also holds the return value of qe_muram_alloc.
Arnd
^ permalink raw reply
* Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion
From: Luis R. Rodriguez @ 2016-08-02 7:41 UTC (permalink / raw)
To: Daniel Wagner
Cc: Luis R. Rodriguez, Dmitry Torokhov, Arend van Spriel,
Bjorn Andersson, Daniel Wagner, Bastien Nocera,
Greg Kroah-Hartman, Johannes Berg, Kalle Valo, Ohad Ben-Cohen,
Mimi Zohar, David Howells, Andy Lutomirski, David Woodhouse,
Julia Lawall, linux-input, linux-kselftest, linux-wireless,
linux-kernel
In-Reply-To: <2713d779-ef55-793d-f37e-d1414bb1bfc2@bmw-carit.de>
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 rather is to provide a flexible API first,
> >>>compartamentalizing the usermode helper was secondary. But now it seems
> >>>I may just also add devm support too to help simplify code further.
> >>
> >>I missed the point that you plan to add usermode helper support to
> >>the sysdata API.
> >
> >I had no such plans, when I have asked folks so far about "hey are you
> >really in need for it, OK what for? " and "what extended uses do you
> >envision?" so I far I have not gotten any replies at all. So -- instead
> >sysdata currently ignores it.
>
> So you argue for the remoteproc use case with 100+ MB firmware that
> if there is a way to load after pivot_root() (or other additional
> firmware partition shows up) then there is no need at all for
> usermode helper?
No, I'm saying I'd like to hear valid uses cases for the usermode helper and so
far I have only found using coccinelle grammar 2 explicit users, that's it. My
patch series (not yet merge) then annotates these as valid as I've verified
through their documentation they have some quirky requirement.
Other than these two drivers I'd like hear to valid requirements for it.
The existential issue is a real issue but it does not look impossible to
resolve. It may be a solution to bloat up the kernel with 100+ MB size just to
stuff built-in firmware to avoid this issue, but it does not mean a solution
is not possible.
Remind me -- why can remoteproc not stuff the firmware in initramfs ?
Anyway, here's a simple suggestion: fs/exec.c gets a sentinel file monitor
support per enum kernel_read_file_id. For instance we'd have one for
READING_FIRMWARE, one for READING_KEXEC_IMAGE, perhaps READING_POLICY, and this
would in turn be used as the system configurable deterministic file for
which to wait for to be present before enabling each enum kernel_read_file_id
type read.
Thoughts ?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Masashi Honma @ 2016-08-02 8:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, j, me
In-Reply-To: <1470124071.2665.12.camel@sipsolutions.net>
On 2016年08月02日 16:47, Johannes Berg wrote:
> Can you elaborate why? Does it fix anything? Please resend the patch
> with that (and perhaps the "subfield" typo fixed above).
I see.
Masashi Honma.
^ permalink raw reply
* Re: [PATCH] mac80211: End the MPSP even if EOSP frame was not received
From: Johannes Berg @ 2016-08-02 7:47 UTC (permalink / raw)
To: Masashi Honma; +Cc: linux-wireless, j, me
In-Reply-To: <1468393475-2483-1-git-send-email-masashi.honma@gmail.com>
On Wed, 2016-07-13 at 16:04 +0900, Masashi Honma wrote:
> The mesh STA sends QoS frame with EOSP (end of service period)
> subfiled=1 to end the MPSP(mesh peer service period). Previously, if
> the frame was not acked by peer, the mesh STA did not end the MPSP.
> This patch ends the MPSP even if the QoS frame was no acked.
>
Can you elaborate why? Does it fix anything? Please resend the patch
with that (and perhaps the "subfield" typo fixed above).
johannes
^ permalink raw reply
* Re: [PATCH] cfg80211: fix missing break in NL8211_CHAN_WIDTH_80P80 case
From: Johannes Berg @ 2016-08-02 7:44 UTC (permalink / raw)
To: Colin King, David S . Miller, linux-wireless, netdev; +Cc: linux-kernel
In-Reply-To: <1468781727-9906-1-git-send-email-colin.king@canonical.com>
On Sun, 2016-07-17 at 19:55 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The switch on chandef->width is missing a break on the
> NL8211_CHAN_WIDTH_80P80 case; currently we get a WARN_ON when
> center_freq2 is non-zero because of the missing break.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix check for buffered powersave frames with txq
From: Johannes Berg @ 2016-08-02 7:45 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless
In-Reply-To: <20160711130915.86284-1-nbd@nbd.name>
On Mon, 2016-07-11 at 15:09 +0200, Felix Fietkau wrote:
> The logic was inverted here, set the bit if frames are pending.
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: rx: frames received out of order
From: Johannes Berg @ 2016-08-02 7:49 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Meirav Kama, David S. Miller, linux-wireless, netdev
In-Reply-To: <20160713115758.25395-1-yanivma@ti.com>
On Wed, 2016-07-13 at 14:57 +0300, Yaniv Machani wrote:
> From: Meirav Kama <meiravk@ti.com>
>
> Upon forwarding frames from Rx to Tx in mesh, driver clones the skb.
> It zeros the tx_info and doesn't set hw_queue correctly. It then
> enqueues
> the frame in queue 0 (VOICE) instead of the correct queue.
> Upon re-queue of this frame, driver inserts it to the correct queue
> (e.g. BE).
> After that, driver dequeue frames from 2 different queues and sends
> them out of order.
> To fix this, driver will set the tx_info->hw_queue to the correct
> queue when cloning the skb.
>
Makes sense, but the subject is a bit misleading - can you come up with
a better one?
johannes
^ permalink raw reply
* Re: [PATCH v2 1/3] mac80211: mesh: flush stations before beacons are stopped
From: Johannes Berg @ 2016-08-02 8:45 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Maital Hahn, David S. Miller, linux-wireless, netdev
In-Reply-To: <20160713114449.24665-1-yanivma@ti.com>
On Wed, 2016-07-13 at 14:44 +0300, Yaniv Machani wrote:
> From: Maital Hahn <maitalm@ti.com>
>
> Some drivers (e.g. wl18xx) expect that the last stage in the
> de-initialization process will be stopping the beacons, similar to AP
> flow.
> Update ieee80211_stop_mesh() flow accordingly.
> As peers can be removed dynamically, this would not impact other
> drivers.
>
Applied.
johannes
^ permalink raw reply
* [PATCH v2] mac80211: End the MPSP even if EOSP frame was not acked
From: Masashi Honma @ 2016-08-02 8:16 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, j, me, Masashi Honma
In-Reply-To: <1468393475-2483-1-git-send-email-masashi.honma@gmail.com>
If QoS frame with EOSP (end of service period) subfield=1 sent by local
peer was not acked by remote peer, local peer did not end the MPSP. This
prevents local peer from going to DOZE state. And if the remote peer
goes away without closing connection, local peer continues AWAKE state
and wastes battery.
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
---
net/mac80211/status.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index c6d5c72..a2a6826 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -771,6 +771,13 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
clear_sta_flag(sta, WLAN_STA_SP);
acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
+
+ /* mesh Peer Service Period support */
+ if (ieee80211_vif_is_mesh(&sta->sdata->vif) &&
+ ieee80211_is_data_qos(fc))
+ ieee80211_mpsp_trigger_process(
+ ieee80211_get_qos_ctl(hdr), sta, true, acked);
+
if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
/*
* The STA is in power save mode, so assume
@@ -781,13 +788,6 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
return;
}
- /* mesh Peer Service Period support */
- if (ieee80211_vif_is_mesh(&sta->sdata->vif) &&
- ieee80211_is_data_qos(fc))
- ieee80211_mpsp_trigger_process(
- ieee80211_get_qos_ctl(hdr),
- sta, true, acked);
-
if (ieee80211_hw_check(&local->hw, HAS_RATE_CONTROL) &&
(ieee80211_is_data(hdr->frame_control)) &&
(rates_idx != -1))
--
2.7.4
^ permalink raw reply related
* [PATCH] mac80211: fix purging multicast PS buffer queue
From: Felix Fietkau @ 2016-08-02 9:13 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
The code currently assumes that buffered multicast PS frames don't have
a pending ACK frame for tx status reporting.
However, hostapd sends a broadcast deauth frame on teardown for which tx
status is requested. This can lead to the "Have pending ack frames"
warning on module reload.
Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
net/mac80211/cfg.c | 2 +-
net/mac80211/tx.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 47e99ab8..543b1d4 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -869,7 +869,7 @@ static int ieee80211_stop_ap(struct wiphy *wiphy, struct net_device *dev)
/* free all potentially still buffered bcast frames */
local->total_ps_buffered -= skb_queue_len(&sdata->u.ap.ps.bc_buf);
- skb_queue_purge(&sdata->u.ap.ps.bc_buf);
+ ieee80211_purge_tx_queue(&local->hw, &sdata->u.ap.ps.bc_buf);
mutex_lock(&local->mtx);
ieee80211_vif_copy_chanctx_to_vlans(sdata, true);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 91461c4..5023966 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -368,7 +368,7 @@ static void purge_old_ps_buffers(struct ieee80211_local *local)
skb = skb_dequeue(&ps->bc_buf);
if (skb) {
purged++;
- dev_kfree_skb(skb);
+ ieee80211_free_txskb(&local->hw, skb);
}
total += skb_queue_len(&ps->bc_buf);
}
@@ -451,7 +451,7 @@ ieee80211_tx_h_multicast_ps_buf(struct ieee80211_tx_data *tx)
if (skb_queue_len(&ps->bc_buf) >= AP_MAX_BC_BUFFER) {
ps_dbg(tx->sdata,
"BC TX buffer full - dropping the oldest frame\n");
- dev_kfree_skb(skb_dequeue(&ps->bc_buf));
+ ieee80211_free_txskb(&tx->local->hw, skb_dequeue(&ps->bc_buf));
} else
tx->local->total_ps_buffered++;
@@ -4275,7 +4275,7 @@ ieee80211_get_buffered_bc(struct ieee80211_hw *hw,
sdata = IEEE80211_DEV_TO_SUB_IF(skb->dev);
if (!ieee80211_tx_prepare(sdata, &tx, NULL, skb))
break;
- dev_kfree_skb_any(skb);
+ ieee80211_free_txskb(hw, skb);
}
info = IEEE80211_SKB_CB(skb);
--
2.8.4
^ permalink raw reply related
* [RESEND PATCH] MAINTAINERS: Update maintainer entry for wilc1000
From: Nicolas Ferre @ 2016-08-02 9:49 UTC (permalink / raw)
To: luisbg, Greg Kroah-Hartman, Andrew Morton, linux-kernel,
linux-wireless
Cc: loic.lefort, aditya.shankar, ganesh.krishna, devel,
Aditya Shankar, Nicolas Ferre
In-Reply-To: <578424eb.gTszFlACY5dPKGsR%akpm@linux-foundation.org>
From: Aditya Shankar <Aditya.Shankar@microchip.com>
Take the maintenance of the Atmel WIFI staging driver wilc1000.
Former maintainers are no more with Atmel.
Reported-by: Loic Lefort <loic.lefort@atmel.com>
Signed-off-by: Aditya Shankar <aditya.shankar@microchip.com>
Signed-off-by: Ganesh Krishna <ganesh.krishna@microchip.com>
Acked-by: Luis de Bethencourt <luisbg@osg.samsung.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Hi all,
Just an elaborate "ping" with the Acked-by tag from Luis added.
As noted by Luis, previous version of this patch is here:
https://lkml.org/lkml/2016/6/27/382
Thanks, bye.
MAINTAINERS | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 33d7e2252ceb..b0d5c77c9db2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11202,12 +11202,8 @@ S: Odd Fixes
F: drivers/staging/vt665?/
STAGING - WILC1000 WIFI DRIVER
-M: Johnny Kim <johnny.kim@atmel.com>
-M: Austin Shin <austin.shin@atmel.com>
-M: Chris Park <chris.park@atmel.com>
-M: Tony Cho <tony.cho@atmel.com>
-M: Glen Lee <glen.lee@atmel.com>
-M: Leo Kim <leo.kim@atmel.com>
+M: Aditya Shankar <aditya.shankar@microchip.com>
+M: Ganesh Krishna <ganesh.krishna@microchip.com>
L: linux-wireless@vger.kernel.org
S: Supported
F: drivers/staging/wilc1000/
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox