On Fri, May 12, 2017 at 11:02:26PM +0200, Arend Van Spriel wrote:
> try again.. replacing email address from Michał
> On 12-5-2017 22:55, Arend Van Spriel wrote:
> > Let me explain the idea to refresh your memory (and mine). It started
> > when we were working on adding driver support for OpenWrt i
On Tue, May 16, 2017 at 12:06:50AM +0200, Luis R. Rodriguez wrote:
> Using QEMU emulator version 2.7.94 (v2.8.0-rc4-dirty)
>
> I will try updating my distro package for qemu and see if perhaps its this
> and for the other odd fork issue I reported [0].
>
> [0]
> https://
For a few kernel releases now I have managed to trigger the warning added via
commit e1a58320a38dfa ("x86/mm: Warn on W^X mappings", merged upstream since
v4.4) on my KVM qemu x86_64 system. Since I just booted into the shiny new
linux-next tag next-20170515 (based on v4.12-rc1) and this is still t
On Fri, Feb 17, 2017 at 11:32:34AM -0800, Andy Lutomirski wrote:
> On Fri, Feb 17, 2017 at 9:23 AM, Luis R. Rodriguez wrote:
> > On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski
> > wrote:
> >> But maybe
> >> there really is a race in which a kmemleak
kernel API. This gives us the flexibility to build test case from
userspace with less kernel changes.
Signed-off-by: Luis R. Rodriguez
---
Greg,
This v8 fixes a test driver unload issue, and a configuration typo spotted by
AKASHI. Its the only issue discovered during review on the v7 series of the
On Fri, May 12, 2017 at 05:52:18PM +0200, Luis R. Rodriguez wrote:
> On Fri, May 12, 2017 at 09:20:24AM +0900, AKASHI Takahiro wrote:
> > On Thu, May 11, 2017 at 08:26:29PM +0200, Luis R. Rodriguez wrote:
> > > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
>
On Fri, May 12, 2017 at 09:28:47AM +0900, AKASHI Takahiro wrote:
> On Thu, May 11, 2017 at 11:32:30AM -0700, Luis R. Rodriguez wrote:
> > On Thu, May 11, 2017 at 11:26 AM, Luis R. Rodriguez wrote:
> > >
> > > It would seems to make sense to me to only need to verify fi
On Fri, May 12, 2017 at 09:20:24AM +0900, AKASHI Takahiro wrote:
> On Thu, May 11, 2017 at 08:26:29PM +0200, Luis R. Rodriguez wrote:
> > On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> > > On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
>
On Thu, May 11, 2017 at 11:26 AM, Luis R. Rodriguez wrote:
>
> It would seems to make sense to me to only need to verify files when read
> for the first time, once its cache I don't see why we would re-verify them ?
To be clear, the fw cache feature reads the files from the fs pr
On Thu, May 11, 2017 at 01:17:39PM -0500, Li, Yi wrote:
> On 5/2/2017 3:49 AM, Luis R. Rodriguez wrote:
> > As the firmware API evolves we keep extending functions with more arguments.
> > Stop this nonsense by proving an extensible data structure which can be used
> > t
On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > diff --git a/tools/testing/selftests/firmware/driver_data.sh
> > > > b/tools/testing/selftests/firmware/driver_data.sh
>
On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > diff --git a/lib/test_driver_data.c b/lib/test_driver_data.c
> > > > new file mode 100644
> > > > index 0
Sorry this is an old topic now but a clarification was requested by AKASHI,
so following up.
On Tue, Aug 09, 2016 at 07:58:27PM -0700, Linus Torvalds wrote:
> On Tue, Aug 9, 2016 at 1:14 PM, Luis R. Rodriguez wrote:
> >
> > I'm personally fine with MODULE_LICENSE(&q
On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> Luis,
>
> On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > +To test an async call one could do::
> > > > +
> > > > +echo anything > /lib/firmwar
On Thu, May 11, 2017 at 07:10:18PM +0900, AKASHI Takahiro wrote:
> Luis,
>
> On Tue, May 02, 2017 at 01:49:12AM -0700, Luis R. Rodriguez wrote:
> >
> > diff --git a/lib/test_driver_data.c b/lib/test_driver_data.c
> > new file mode 100644
> > index 000
On Wed, May 03, 2017 at 09:02:20PM +0200, Arend Van Spriel wrote:
> On 3-1-2017 18:59, Luis R. Rodriguez wrote:
> > On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote:
> >>
> >> Right question is "should we solve it without user-space help"?
> &g
The driver data API provides support for looking for firmware
from a specific set of API ranges, so just use that. Since we
free the firmware on the callback immediately after consuming it,
this also takes avantage of that feature.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel
This documents the driver data API.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/driver_data.rst | 167 +
Documentation/driver-api/firmware/index.rst| 1 +
Documentation/driver-api/firmware/introduction.rst | 16 ++
.../driver-api
code
more appropriately unde CONFIG_FW_LOADER_USER_HELPER_FALLBACK.
This commit should introduces no functional changes (TM).
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 331 --
include/linux/driver_data.h | 82 +++
2 fil
ronous requests
through the same two basic set of APIs.
- A firmware API framework is provided to enable daisy chaining a
series of requests for firmware on a range of supported APIs.
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS | 3 +-
drivers/base/firmwar
kernel API. This gives us the flexibility to build test case from
userspace with less kernel changes.
Signed-off-by: Luis R. Rodriguez
---
MAINTAINERS |1 +
lib/Kconfig.debug | 12 +
lib/Makefile
next.git/log/?h=v4.11-rc8-driver-data-try3
Luis R. Rodriguez (5):
firmware: add extensible driver data params
firmware: add extensible driver data API
test: add new driver_data load tester
firmware: document the extensible driver data API
iwlwifi: convert to use driver data API
Documenta
This routine will used in functions declared earlier next. This
code shift has no functional changes, it will make subsequent
changes easier to read.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 32
1 file changed, 16 insertions(+), 16
inux-next.git/log/?h=20170501-driver-data-try2
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/?h=v4.11-rc8-driver-data-try3
Luis R. Rodriguez (6):
firmware: move kill_requests_without_uevent() up above
firmware: share fw fallback killing on reboot/suspend
firmwar
Now that we've have proper wrappers for the fallback mechanism
we can easily share the reboot notifier for the firmware_class
at all times.
This change will make subsequent modifications to the reboot
notifier easier to review.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_cl
We kill pending fallback requests on suspend and reboot,
the only difference is that on suspend we only kill custom
fallback requests. Provide a wrapper that lets us customize
the request with a flag.
This also lets us simplify the #ifdef'ery over the calls.
Signed-off-by: Luis R. Rodr
tore() callbacks and there was no
direct fs lookups or the firmware cache.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 68 +++
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/
This will make subsequent changes easier to read.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 77 +--
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
those cases.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 11 +++
drivers/base/firmware_class.c | 99 ++
2 files changed, 110 insertions(+)
diff --git a/Documentation/driver-api/firmware/request_firmware.rst
On Fri, Apr 28, 2017 at 12:19:05PM +0900, AKASHI Takahiro wrote:
> > > > + ret = _request_firmware(&driver_data, name, ¶ms, device);
> > > > + if (ret && driver_data_param_optional(req_params))
> > > > + ret = driver_data_sync_opt_call_cb(req_params);
> > > > + else
On Tue, Apr 11, 2017 at 05:32:52PM +0900, AKASHI Takahiro wrote:
> On Wed, Mar 29, 2017 at 08:25:12PM -0700, Luis R. Rodriguez wrote:
> > This adds a load tester driver test_driver_data a for the new extensible
> > driver_data loader API, part of firmware_class. This test driver ena
On Mon, Apr 10, 2017 at 04:19:12PM +0300, Luca Coelho wrote:
> On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote:
> > The driver data API provides support for looking for firmware
> > from a specific set of API ranges, so just use that. Since we
> > free the fir
On Thu, Apr 13, 2017 at 06:36:17PM +0900, AKASHI Takahiro wrote:
> On Wed, Mar 29, 2017 at 08:25:11PM -0700, Luis R. Rodriguez wrote:
> > Signed-off-by: Luis R. Rodriguez
> > ---
> > Documentation/driver-api/firmware/driver_data.rst | 77 +
> > Documentation/dr
On Thu, Apr 27, 2017 at 09:09:47AM +0300, Luca Coelho wrote:
> On Thu, 2017-04-27 at 05:16 +0200, Luis R. Rodriguez wrote:
> > > > +int driver_data_request_sync(const char *name,
> > > > + const struct driver_data_req_
On Thu, Apr 27, 2017 at 08:44:27AM +0300, Luca Coelho wrote:
> On Thu, 2017-04-27 at 05:16 +0200, Luis R. Rodriguez wrote:
> > > > @@ -1460,6 +1471,128 @@ void release_firmware(const struct firmware *fw)
> > > > }
> > > > EXPORT_SYMBOL(release_fi
On Tue, Apr 11, 2017 at 05:01:51PM +0900, takahiro.aka...@linaro.org wrote:
> On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote:
> > On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote:
> > > +Driver data
On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote:
> On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote:
> > The firmware API does not scale well: when new features are added we
> > either add a new exported symbol or extend the arguments of existing
> &
On Thu, Apr 06, 2017 at 10:26:12AM +0300, Luca Coelho wrote:
> On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote:
> > Signed-off-by: Luis R. Rodriguez
> > ---
>
> Looks fine with a few nitpicks.
>
>
> > diff --git a/drivers/base/firmware_class.
On Thu, Apr 06, 2017 at 06:38:47AM +, Coelho, Luciano wrote:
> Hi Luis,
> > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> > index ac350c518e0c..d2e2d83aaf26 100644
> > --- a/drivers/base/firmware_class.c
> > +++ b/drivers/base/firmware_class.c
> > @@ -562,16 +562,
On Wed, Mar 29, 2017 at 08:25:14PM -0700, Luis R. Rodriguez wrote:
> The requested nvram is optional, don't nag users about this.
> Additionally, the new driver data API enables us to let the API
> deal with the freeing of the nvram for us if we happen to free
> it immediatel
On Thu, Apr 06, 2017 at 01:11:57PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 06, 2017 at 12:53:12PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Apr 06, 2017 at 11:26:36AM +0100, Lorenzo Pieralisi wrote:
> > > Indeed, the static inline ioremap_nocache() fallback does
On Thu, Apr 06, 2017 at 12:38:45PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Apr 06, 2017 at 12:53:12PM +0200, Luis R. Rodriguez wrote:
> > On Thu, Apr 06, 2017 at 11:26:36AM +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Apr 05, 2017 at 01:38:12PM +0100, Lorenzo Pieralisi wro
On Thu, Apr 06, 2017 at 11:26:36AM +0100, Lorenzo Pieralisi wrote:
> On Wed, Apr 05, 2017 at 01:38:12PM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Apr 05, 2017 at 11:58:41AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Mar 28, 2017 at 03:45:43PM +0100, Lorenzo Pieralisi wrote:
> > > > On M
On Tue, Mar 14, 2017 at 5:53 PM, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 06:59:12PM -0800, Sodagudi Prasad wrote:
>> On 2017-01-03 07:19, Greg KH wrote:
>> > On Tue, Jan 03, 2017 at 06:44:03AM -0800, Sodagudi Prasad wrote:
>> > >
>> > > Hi Al
On Fri, Mar 24, 2017 at 04:01:58PM -0400, Ben Gamari wrote:
> Greg Kroah-Hartman writes:
>
> > On Fri, Jan 06, 2017 at 10:54:38PM +0100, Yves-Alexis Perez wrote:
> >> On Fri, 2017-01-06 at 22:43 +0100, Greg Kroah-Hartman wrote:
> >> > 4.8-stable review patch. If anyone has any objections, please
ernel/kmod.c thing than firmware thing.
This changes makes subsequent patches able to fold the new driver data
API onto the older firmware API. These all go hammered with 0-day and
the firmware test scripts shipped upstream.
Luis R. Rodriguez (5):
firmware: share fw fallback killing on reboot/su
those cases.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 11 +++
drivers/base/firmware_class.c | 96 ++
2 files changed, 107 insertions(+)
diff --git a/Documentation/driver-api/firmware/request_firmware.rst
kernel API. This gives us the flexibility to build test case from
userspace with less kernel changes.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/driver_data.rst | 32 +
MAINTAINERS |1 +
lib/Kconfig.debug
nally based on patches by Rafał Miłecki.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
b/drivers/net/wir
will make subsequent changes easier to review which will
be adding new flexible APIs.
This commit should introduces no functional changes (TM).
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 217 +++---
include/linux/driver_data.h
ronous requests
through the same two basic set of APIs.
- A firmware API framework is provided to enable daisy chaining a
series of requests for firmware on a range of supported APIs.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/driver_data.rst | 77 +
Documenta
tore() callbacks and there was no
direct fs lookups or the firmware cache.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 68 +++
1 file changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/
The driver data API provides support for looking for firmware
from a specific set of API ranges, so just use that. Since we
free the firmware on the callback immediately after consuming it,
this also takes avantage of that feature.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel
R. Rodriguez (5):
firmware: add extensible driver data params
firmware: add extensible driver data API
test: add new driver_data load tester
iwlwifi: convert to use driver data API
brcmfmac: don't warn user if requested nvram fails
Documentation/driver-api/firmware/driver_dat
This will make subsequent changes easier to read.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_class.c | 77 +--
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
Now that we've have proper wrappers for the fallback mechanism
we can easily share the reboot notifier for the firmware_class
at all times.
This change will make subsequent modifications to the reboot
notifier easier to review.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_cl
We kill pending fallback requests on suspend and reboot,
the only difference is that on suspend we only kill custom
fallback requests. Provide a wrapper that lets us customize
the request with a flag.
This also lets us simplify the #ifdef'ery over the calls.
Signed-off-by: Luis R. Rodr
On Thu, Mar 09, 2017 at 06:18:09PM -0600, yi1...@linux.intel.com wrote:
> From: Yi Li
>
> Add function to load firmware in multiple chucks instead of
>
> loading the whole big firmware file at once.
>
> Signed-off-by: Yi Li
> ---
> drivers/base/firmware_class.c | 128
> ++
On Fri, Mar 17, 2017 at 06:29:36PM +0100, Luis R. Rodriguez wrote:
> On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote:
> > On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> > > Luis: would you ack this patch now I followed your guidance?
> >
On Thu, Mar 16, 2017 at 11:03:52PM +0900, Greg KH wrote:
> On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> > Luis: would you ack this patch now I followed your guidance?
>
> It's up to Luis now :)
I'm reviewing now!
Luis
On Fri, Mar 17, 2017 at 10:43:39AM +, Liviu Dudau wrote:
> On Fri, Mar 17, 2017 at 01:33:21AM +0100, Luis R. Rodriguez wrote:
> > a) should we then use a Fixes tag for this patch ?
>
> I'm not aware of issues being reported, but Lorenzo might have more info on
> this.
On Thu, Mar 16, 2017 at 04:48:44PM -0500, Bjorn Helgaas wrote:
> [+cc Luis]
>
> On Mon, Feb 27, 2017 at 03:14:13PM +, Lorenzo Pieralisi wrote:
> > According to the PCI local bus specifications (Revision 3.0, 3.2.5),
> > I/O Address space transactions are non-posted. On architectures where
> >
On Thu, Mar 16, 2017 at 04:12:43PM -0500, Bjorn Helgaas wrote:
> [+cc Luis]
>
> On Mon, Feb 27, 2017 at 03:14:14PM +, Lorenzo Pieralisi wrote:
> > The PCI specifications (Rev 3.0, 3.2.5 "Transaction Ordering and
> > Posting") mandate non-posted configuration transactions. As further
> > highli
On Thu, Mar 16, 2017 at 03:46:51PM -0500, Bjorn Helgaas wrote:
> On Thu, Jul 9, 2015 at 7:28 PM, Luis R. Rodriguez
> wrote:
>
> > +/**
> > + * DOC: ioremap() and ioremap_*() variants
> > + *
> > + * If you have an IOMMU your architecture is expected to hav
On Thu, Mar 16, 2017 at 10:43 AM, Masahiro Yamada
wrote:
> Hi Luis,
>
> 2017-03-15 9:53 GMT+09:00 Luis R. Rodriguez :
>> On Sat, Mar 11, 2017 at 02:37:02PM +0900, Masahiro Yamada wrote:
>>> Hi Luis,
>>>
>>>
>>> 2017-01-24 0:07 GMT+09:00 Luis R
On Wed, Mar 15, 2017 at 09:35:29AM +0100, Michal Hocko wrote:
> On Wed 15-03-17 01:14:27, Luis R. Rodriguez wrote:
> > On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote:
> > > On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote:
> > > >
On Sat, Mar 11, 2017 at 02:37:02PM +0900, Masahiro Yamada wrote:
> Hi Luis,
>
>
> 2017-01-24 0:07 GMT+09:00 Luis R. Rodriguez :
> > If you modify the target asm we currently do not force the
> > recompilation of the firmware files. The target asm is in
> > the firmw
On Tue, Feb 21, 2017 at 06:59:12PM -0800, Sodagudi Prasad wrote:
> On 2017-01-03 07:19, Greg KH wrote:
> > On Tue, Jan 03, 2017 at 06:44:03AM -0800, Sodagudi Prasad wrote:
> > >
> > > Hi All,
> > >
> > > Device has crashed due to memory access after free while
> > > pending_fw_head
> > > list acc
On Tue, Mar 14, 2017 at 11:07:38AM -0700, Darrick J. Wong wrote:
> On Tue, Mar 14, 2017 at 05:57:45PM +0100, Luis R. Rodriguez wrote:
> > On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote:
> > > The sole remaining caller of kmem_zalloc_greedy is bulkstat, which use
On Tue, Mar 07, 2017 at 04:35:28PM -0800, Darrick J. Wong wrote:
> The sole remaining caller of kmem_zalloc_greedy is bulkstat, which uses
> it to grab 1-4 pages for staging of inobt records. The infinite loop in
> the greedy allocation function is causing hangs[1] in generic/269, so
> just get ri
The firmware async callback and the opmode registration share
some functionality -- to start the drv's opmode. Move this work
into a helper which is shared. This should help us share fixes
should these diverging code paths change.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/
This lets us offload and share all the final opmode related work
necessary for either an opmode driver or new device. This has the most
impact for opmode drivers as this now offloads opmode start for each
device onto the workqueue.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel
will return immediately
without failure.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
b/drivers/net/wireless/intel/iwlwif
) + 5.1916s (initrd) + 10.8968s
(userspace) = 18.7036s
After these patches:
Startup finished in 2.5468s (kernel) + 4.9536s (initrd) + 10.798s
(userspace) = 18.2994s
Luis R. Rodriguez (2):
iwlwifi: share opmode start work code
iwlwifi: convert final opmode work into a workqueue
drivers/net
effort to load suffices and keeps the driver cleaner.
There no change to the first patch. The second patch just embraces
request_module_nowait() instead of implementing a verifier for a sync
call. The remaining patches from the last series will be sent separately.
Luis R. Rodriguez (2):
iwlwifi: fix
rt is actually the more common path. The other path,
from the async callback is rathe rare (1/8 or so times for me) --
it happens when the the opmode driver's init routine completed
prior to the driver's async callback opmode start call.
Signed-off-by: Luis R. Rodriguez
---
drivers/net
On Tue, Feb 21, 2017 at 09:17:15PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> > On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> > > >
> > > > a) just remove the print and use inst
On Tue, Feb 21, 2017 at 07:15:41PM +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> > >
> > > a) just remove the print and use instead request_module_nowait() (this is
> > > more in alignment of what you
On Tue, Feb 14, 2017 at 08:34:15PM +0100, Luis R. Rodriguez wrote:
> On Mon, Feb 06, 2017 at 11:03:52PM +0100, Luis R. Rodriguez wrote:
> > On Mon, Jan 23, 2017 at 07:07:27AM -0800, Luis R. Rodriguez wrote:
> > > If you modify the target asm we currently do not force the
> >
On Tue, Feb 21, 2017 at 07:16:16AM +, Grumbach, Emmanuel wrote:
> >
> > a) just remove the print and use instead request_module_nowait() (this is
> > more in alignment of what your code actually does today; or
> >
> > b) fix the request_module() use so that the error print matches the
> > exp
On Tue, Feb 21, 2017 at 10:47:53AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Thu, Feb 16, 2017 at 08:26:35AM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Wed, Feb 15, 2017 at 11:29:47PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreo
On Wed, Feb 15, 2017 at 04:05:13PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> I found handling of FW_OPT_FALLBACK a bit complex. It was defined using
> another option and their values were dependent on kernel config.
>
> It was also non-trivial to follow the code. Some callers were us
> > need to check for is protected with a mutex later used on the
> > module_init() of the module we are asking for. If we were to lock and
> > request_module() we'd deadlock. iwlwifi needs its own wrapper then so it
> > can handle its special locking requirement
hen I see
the list is empty.
I have a feeling this is then also a rare rarely observed by your QA team
as well, so this code then is also stitching together a set of sequence
calls for both paths.
> > Signed-off-by: Luis R. Rodriguez
> > ---
>
> Luca is OOO, but this looks fine to me.
Reviewed-by ?
Luis
On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski wrote:
> But maybe
> there really is a race in which a kmemleak check right in the middle
> of duplicating the task struct really can't see the stack pointer.
Funny, but it was actually using kmemleak how I can easily reproduce:
To reproduce the k
The firmware async callback and the opmode registration share
some functionality -- to start the drv's opmode. Move this work
into a helper which is shared. This should help us share fixes
should these diverging code paths change.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/
x27;d deadlock. iwlwifi needs its own wrapper then so
it can handle its special locking requirements.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 34
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/
rt is actually the more common path. The other path,
from the async callback is rathe rare (1/8 or so times for me) --
it happens when the the opmode driver's init routine completed
prior to the driver's async callback opmode start call.
Signed-off-by: Luis R. Rodriguez
---
drivers/net
d in 2.5612s (kernel) + 5.3274s (initrd) +
11.0226s (userspace) = 18.9122s
patch-04 Startup finished in 2.5475s (kernel) + 5.0895s (initrd) +
10.9272s (userspace) = 18.5652s
[0]
https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20170206-driver-data-try2
Lu
This lets us offload and share all the final opmode related work
necessary for either an opmode driver or new device. This has the most
impact for opmode drivers as this now offloads opmode start for each
device onto the workqueue.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel
This helps us compartmentalize all last required opmode work
and declutter the async firmware callback.
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 33 +++-
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers
On Wed, Feb 15, 2017 at 10:12:07AM -0800, h...@zytor.com wrote:
> On February 15, 2017 6:41:56 AM PST, Chao Peng
> wrote:
> >Multiboot specification
> >(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2)
> >is an open standard that provides kernels with a uniform way
On Mon, Feb 06, 2017 at 11:03:52PM +0100, Luis R. Rodriguez wrote:
> On Mon, Jan 23, 2017 at 07:07:27AM -0800, Luis R. Rodriguez wrote:
> > If you modify the target asm we currently do not force the
> > recompilation of the firmware files. The target asm is in
> > the firmwa
ious
checks. We keep iterating on the table even if an error is found so
we can complain for all errors found in one shot. This works as
-EINVAL is always returned on error anyway, and the check for error
is any non-zero value.
Fixes: 7c60c48f58a7 ("sysctl: Improve the sysctl sanity checks&quo
Add a few initial respective tests for an array:
o Echoing values separated by spaces works
o Echoing only first elements will set first elements
o Confirm PAGE_SIZE limit still applies even if an array is used
Signed-off-by: Luis R. Rodriguez
---
lib/test_sysctl.c
t the existing scripts to
use it. This will make it easier for further tests to be added.
Signed-off-by: Luis R. Rodriguez
---
lib/Kconfig.debug | 11 +++
lib/Makefile| 1 +
lib/test_sysctl.c
Molnar
Cc: Andrew Morton
Cc: Linus Torvalds
Fixes: e7d316a02f68 ("sysctl: handle error writing UINT_MAX to u32 fields")
Signed-off-by: Luis R. Rodriguez
---
fs/proc/proc_sysctl.c | 15 +
kernel/sysctl.c | 161 --
2 files chan
Test against a simple proc_dointvec() case. While at it, add
a test against INT_MAX. Make sure INT_MAX works, and INT_MAX+1
will fail. Also test negative values work.
Signed-off-by: Luis R. Rodriguez
---
lib/test_sysctl.c| 11 ++
tools/testing/selftests/sysctl
801 - 900 of 3127 matches
Mail list logo
