of times, say we want to run
a test case 100 times:
./sysctl.sh -c 0001 100
To run a test case only once, for example:
./sysctl.sh -s 0002
The default settings are specified at the top of sysctl.sh.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/sysctl/Makefile | 3
Test against a simple proc_douintvec() case. While at it, add
a test against UINT_MAX. Make sure UINT_MAX works, and UINT_MAX+1
will fail and that negative values are not accepted.
Signed-off-by: Luis R. Rodriguez
---
lib/test_sysctl.c| 11 ++
tools/testing/selftests
shell reset_vals() with a reset to values we know
are set at init on the driver.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/sysctl/sysctl.sh | 65
1 file changed, 65 insertions(+)
diff --git a/tools/testing/selftests/sysctl/sysctl.sh
b/tools
: Heinrich Schuchardt
Cc: Kees Cook
Cc: "David S. Miller"
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Linus Torvalds
Signed-off-by: Luis R. Rodriguez
---
fs/proc/proc_sysctl.c | 4 ++-
include/linux/sysctl.h | 3 +++
kernel/sysctl.c| 66 +++
. I'm of the opinion that
sysctl_check_table() should just validate this and bail preventing such
entries from ever creeping up. The only reason I didn't do this is this
*could* mean some tables don't get registered in some cases -- I haven't
done the vetting. If we're fine w
Fixes: e180a6b7759a ("param: fix charp parameters set via sysfs")
Reviewed-by: Miroslav Benes
Reviewed-by: Aaron Tomlin
Signed-off-by: Luis R. Rodriguez
---
kernel/module.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/module.c b/kernel/module.c
index 38d4270925d4..8409a82424d
On Wed, Feb 01, 2017 at 08:56:46PM +0100, Luis R. Rodriguez wrote:
> On Mon, Jan 30, 2017 at 03:56:20PM +0300, Alexey Dobriyan wrote:
> > On Sun, Jan 29, 2017 at 10:29 PM, Luis R. Rodriguez
> > wrote:
> > > Commit e7d316a02f6838 ("sysctl: handle error writing
On Tue, Feb 07, 2017 at 09:03:43AM +0100, Michal Hocko wrote:
> On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote:
> > > From a quick check I do not see any leak there either.
> >
> > Then in that case what about:
>
> This just disables the kmemleak altogether whi
On Wed, Feb 8, 2017 at 5:28 PM, Luis R. Rodriguez wrote:
> So unless anyone finds evidence to the contrary I will be ripping
> out array support from unsigned int
Oh so I should probably explain: the reason for this is that even
though I found one possible user for array for unsigned i
0-day caught a compile issue after the commit titled (kprobes: move
kprobe declarations to asm-generic/kprobes.h) was applied. This fixes
that.
Reported-by: 0-day
Cc: Mark Brown
Cc: Masami Hiramatsu
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Luis R. Rodriguez
---
As seen on linux
On Mon, Feb 06, 2017 at 10:47:41AM +0100, Michal Hocko wrote:
> On Fri 03-02-17 13:06:04, Luis R. Rodriguez wrote:
> > On next-20170125 running some kselftest not yet upstream I eventually
> > get a kmemleak splat:
> >
> > unreferenced object 0xa7b1034b40
hrough the same two basic set of APIs.
- You no longer need to declare and use your own completions, you
can replace your completions with driver_data_synchronize_request()
using the async_cookie given back by the async driver data call.
Signed-off-by: Luis R. Rodriguez
---
Documenta
and uses the
READING_FIRMWARE id only as this is where the code grew from.
Luis R. Rodriguez (2):
firmware: add extensible driver data API
test: add new driver_data load tester
Documentation/driver-api/firmware/driver_data.rst | 109 ++
Documentation/driver-api/firmware/index.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
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 firmware/Makefile, peg this file as a dependency to
> require re-compilation of firmware
On Sun, Feb 05, 2017 at 11:33:25AM +0100, Borislav Petkov wrote:
> On Sat, Feb 04, 2017 at 05:22:55PM -0800, Guenter Roeck wrote:
> > Upstream (v4.10-rc6-193-ga572a1b99948), the same command yields no error at
> > all:
>
> That's because you tested Linus' merge commit of the branch which fixed th
I could not boot next-20170203 on my x86_64 qemu instance. It stalls at:
[0.015549] CPU: Physical Processor ID: 0
[0.015842] mce: CPU supports 10 MCE banks
[0.016032] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[0.016393] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[0.
both kprobes and ftrace, that of the
definition of the breakput instruction up. Some refer to this as
BREAKPOINT_INSTRUCTION. This must be kept outside of the #ifdef
CONFIG_KPROBES guard.
Acked-by: Masami Hiramatsu
Signed-off-by: Luis R. Rodriguez
---
This patch was part of a larger series, i
On Wed, Feb 01, 2017 at 10:00:57PM -0500, Steven Rostedt wrote:
> On Wed, 1 Feb 2017 22:46:04 +0100
> "Luis R. Rodriguez" wrote:
>
> > On Thu, Jan 19, 2017 at 03:47:35PM +0900, Masami Hiramatsu wrote:
> > > OK, then it is OK to me.
> > >
>
On Thu, Jan 19, 2017 at 10:58:56AM -0800, Bjorn Andersson wrote:
> On Thu 12 Jan 07:02 PST 2017, Luis R. Rodriguez wrote:
> [..]
> > +Fallback mechanisms on the driver data API
> > +==
> > +
> > +The old firmware API provided su
4+0x0/0x6a
[] 0x
Signed-off-by: Luis R. Rodriguez
---
I can reproduce this over time on a qemu box running next-20170125.
After running this for a while I no longer see the splat. This needs
confirmation form folks more familiar with the code, hence RFC. If
this is a real f
ll here as this is never modular,
so just white list it.
Signed-off-by: Luis R. Rodriguez
---
kernel/ucount.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/ucount.c b/kernel/ucount.c
index 68716403b261..8a11fc0cb459 100644
--- a/kernel/ucount.c
+++ b/kernel/ucou
On next-20170125 running some kselftest not yet upstream I eventually
get a kmemleak splat:
unreferenced object 0xa7b1034b4000 (size 16384):
comm "driver_data.sh", pid 6506, jiffies 4295068366 (age 1697.272s)
hex dump (first 32 bytes):
9d 6e ac 57 00 00 00 00 74 2d 64 72 69 76 65 72 .
On Thu, Jan 19, 2017 at 03:47:35PM +0900, Masami Hiramatsu wrote:
> OK, then it is OK to me.
>
> Acked-by: Masami Hiramatsu
Aha, actually I *did* send this out separately already :) --
who's tree should this go through ?
Luis
On Mon, Jan 30, 2017 at 03:56:20PM +0300, Alexey Dobriyan wrote:
> On Sun, Jan 29, 2017 at 10:29 PM, Luis R. Rodriguez wrote:
> > Commit e7d316a02f6838 ("sysctl: handle error writing UINT_MAX to u32
> > fields")
> > added proc_douintvec() to start help adding sup
r writing UINT_MAX to u32 fields")
Signed-off-by: Luis R. Rodriguez
---
I split this off as its own atomic fix from a larger RFC series [0].
I've only provided the fix here, and split off further functionality
into a separate patch for the future. Although this is a fix I don't thi
On Fri, Jan 27, 2017 at 02:11:46PM +0100, Pali Rohár wrote:
> So there are only two options:
>
> 1) Disallow it and so these users will have non-working wifi.
>
> 2) Allow those data to be used as fallback mechanism.
There is one "custom fallback" user in kernel which we recently
determined was
On Fri, Jan 27, 2017 at 12:53:38PM -0800, Linus Torvalds wrote:
> On Fri, Jan 27, 2017 at 10:23 AM, Luis R. Rodriguez wrote:
> >> So I'm really not seeing why you want to make these conversions that
> >> just make code worse.
> >
> > The real goal here was fi
expect some random maintainer (e.g. wireless tree) to pick it.
> >
> > I don't think you looked very hard:
> >
> > $ ./scripts/get_maintainer.pl --file drivers/base/firmware_class.c
> > Ming Lei (maintainer:FIRMWARE LOADER
> > (request_firmware))
> >
On Thu, Jan 26, 2017 at 01:54:20PM -0800, Linus Torvalds wrote:
> On Thu, Jan 26, 2017 at 1:50 PM, Luis R. Rodriguez wrote:
> >
> > OK I've added a respective helper call which would map 1-1 with the
> > old sync mechanism to enable a 1-1 change, this will be called
>
On Thu, Jan 19, 2017 at 05:27:51PM +0100, Luis R. Rodriguez wrote:
> On Thu, Jan 19, 2017 at 12:38:57PM +0100, Greg KH wrote:
> > On Thu, Jan 12, 2017 at 07:02:44AM -0800, Luis R. Rodriguez wrote:
> > > ---
> > > drivers/net/wireless/intersil/p54/eeprom.c | 2 +-
e ("firmware: Correct handling of fw_state_wait() return
value")
Reported-and-Tested-by: Jakub Kicinski
Reported-and-Tested-by: Patrick Bruenn
Reported-by: Chris Wilson
CC: [3.10+]
Signed-off-by: Luis R. Rodriguez
---
v3: shorten commit log and stick to 72 characters for margins
On Wed, Jan 25, 2017 at 04:47:25PM +0100, Greg KH wrote:
> On Wed, Jan 25, 2017 at 07:21:18AM -0800, Luis R. Rodriguez wrote:
> > Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> > ("firmware: Correct handling of fw_state_wait() return value")
> > fw_load
timeout() returns -ENOENT
-> since mentioned commit
-> fw_load_abort(fw_priv) is called a second time
-> and this time it would call:
-> __fw_load_abort(NULL /* fw_priv->buf */)
-> and we get: NULL->fw_st.status
Fixes: 5d47ec02c37e ("firmware: Correct handling of fw_state_wait() re
On Wed, Jan 25, 2017 at 06:15:42PM +0530, Imran Khan wrote:
> Remove firmware buffer from pending list when it is freed.
> Once the buffer is free kmalloc can allocate the same slab
> object for some other user but as the buffer is still there
> in the pending list, we end up with multiple users of
On Wed, Jan 25, 2017 at 02:36:31PM +0100, Luis R. Rodriguez wrote:
> On Wed, Jan 25, 2017 at 11:52:04AM +0100, Greg KH wrote:
> > On Mon, Jan 23, 2017 at 08:11:11AM -0800, Luis R. Rodriguez wrote:
> > > Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> > > (&qu
On Wed, Jan 25, 2017 at 11:52:04AM +0100, Greg KH wrote:
> On Mon, Jan 23, 2017 at 08:11:11AM -0800, Luis R. Rodriguez wrote:
> > Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> > ("firmware: Correct handling of fw_state_wait() return value")
> > fw_load
any changes. If any APIs are changed we need a respective test unit for it.
Luis R. Rodriguez (7):
test_firmware: move misc_device down
test_firmware: use device attribute groups
tools: firmware: check for distro fallback udev cancel rule
tools: firmware: rename fallback mechanism scri
This will make further changes easier to review.
Signed-off-by: Luis R. Rodriguez
---
lib/test_firmware.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index a3e8ec3fb1c5..1cb9bf9eb41f 100644
--- a/lib/test_firmware.c
Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel
all fallback mechanism uevents immediately. This would obviously
make it hard to test against the fallback mechanism test interface,
so we need to check for this.
Signed-off-by: Luis R. Rodriguez
---
tools/testing
Calling it user mode helper only creates confusion.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/Makefile| 2 +-
.../testing/selftests/firmware/{fw_userhelper.sh => fw_fallback.sh} | 5 +++--
2 files changed, 4 insertions(+), 3 deleti
it
-> fw_load_abort(fw_priv) is called a second time
-> and this time it would call:
-> __fw_load_abort(NULL /* fw_priv->buf */)
-> and we get: NULL->fw_st.status
Fixes: 5d47ec02c37e ("firmware: Correct handling of fw_state_wait() return
value")
Reported-an
Add a test case for cancelling the sync fallback mechanism.
Signed-off-by: Luis R. Rodriguez
---
tools/testing/selftests/firmware/fw_fallback.sh | 32 +
1 file changed, 32 insertions(+)
diff --git a/tools/testing/selftests/firmware/fw_fallback.sh
b/tools/testing
This simplifies init and exit.
Signed-off-by: Luis R. Rodriguez
---
lib/test_firmware.c | 35 +++
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 1cb9bf9eb41f..38cc188c4d3c 100644
--- a/lib
We have no custom fallback mechanism test interface. Provide one.
This tests both the custom fallback mechanism and cancelling the
it.
Signed-off-by: Luis R. Rodriguez
---
lib/test_firmware.c | 45
tools/testing/selftests/firmware/fw_fallback.sh | 68
If you modify the target asm we currently do not force the
recompilation of the firmware files. The target asm is in
the firmware/Makefile, peg this file as a dependency to
require re-compilation of firmware targets when the asm
changes.
Signed-off-by: Luis R. Rodriguez
---
Michal,
I had this
On Mon, Jan 23, 2017 at 9:02 AM, Greg KH wrote:
> On Mon, Jan 23, 2017 at 03:59:52PM +0100, Luis R. Rodriguez wrote:
>> On Thu, Jan 19, 2017 at 11:15:07AM +0100, Greg KH wrote:
>> > On Wed, Jan 18, 2017 at 09:31:56AM -0800, Luis R. Rodriguez wrote:
>> > > If you modi
On Thu, Jan 19, 2017 at 11:15:07AM +0100, Greg KH wrote:
> On Wed, Jan 18, 2017 at 09:31:56AM -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 firmware/Makefil
On Thu, Jan 19, 2017 at 05:14:36PM +0100, Greg KH wrote:
> In short, don't worry about this, it's not a big deal nor really worth
> the effort.
Fine by me, I'll drop these two patches.
Luis
On Thu, Jan 19, 2017 at 12:36:52PM +0100, Greg KH wrote:
> On Thu, Jan 12, 2017 at 07:02:42AM -0800, Luis R. Rodriguez wrote:
>
> I think this changelog novel is longer than the documentation you added
> to the kernel :(
Heh, OK will work on that.
> > --- /dev/null
>
On Thu, Jan 19, 2017 at 12:31:11PM +0100, Greg KH wrote:
> On Thu, Jan 12, 2017 at 06:42:50AM -0800, Luis R. Rodriguez wrote:
> > +Invalid users of the custom fallback mechanism can be policed using::
>
> Ick, no, why? Why not just add a checkpatch rule instead?
If its easy to d
On Thu, Jan 19, 2017 at 12:38:57PM +0100, Greg KH wrote:
> On Thu, Jan 12, 2017 at 07:02:44AM -0800, Luis R. Rodriguez wrote:
> > The Coccinelle sysdata patches were used to help with
> > this transition. The changes have been carefully manually
> > vetted for. With the con
Commit-ID: 85b36c931ff328297572a3e6136fac573795ad79
Gitweb: http://git.kernel.org/tip/85b36c931ff328297572a3e6136fac573795ad79
Author: Luis R. Rodriguez
AuthorDate: Wed, 18 Jan 2017 09:38:04 -0800
Committer: Ingo Molnar
CommitDate: Thu, 19 Jan 2017 08:40:44 +0100
jump_labels: Move
On Wed, Jan 18, 2017 at 06:33:56AM +, linux-kernel-dev wrote:
> >From: Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
> >Sent: Dienstag, 17. Januar 2017 22:18
> >
> >On Tue, Jan 17, 2017 at 12:53 PM, Luis R. Rodriguez
> >wrote:
> >> On Tue,
n x86 where kprobes is disabled but ftrace is
left enabled.
o include on arch/arm64/kernel/probes/decode-insn.h
Signed-off-by: Luis R. Rodriguez
---
This was part of the linker table series [0], but I'm going to split up
patches further there. This is an atomic change which is independent
The ending header guard is misplaced. This has no
functional change, this is just an eye-sore.
Signed-off-by: Luis R. Rodriguez
---
This was part of the linker table series [0], but I'm going to split up
patches further there. This is an atomic change which is independent
so sending
If you modify the target asm we currently do not force the
recompilation of the firmware files. The target asm is in
the firmware/Makefile, peg this file as a dependency to
require re-compilation of firmware targets when the asm
changes.
Signed-off-by: Luis R. Rodriguez
---
Greg,
This was part
On Tue, Jan 17, 2017 at 10:04:20AM -0800, Jakub Kicinski wrote:
> On Tue, Jan 17, 2017 at 9:30 AM, Luis R. Rodriguez wrote:
> > On Tue, Jan 17, 2017 at 08:30:37AM -0800, Jakub Kicinski wrote:
> >> On Tue, Jan 17, 2017 at 8:21 AM, Luis R. Rodriguez
> >> wrote:
>
On Tue, Jan 17, 2017 at 08:30:37AM -0800, Jakub Kicinski wrote:
> On Tue, Jan 17, 2017 at 8:21 AM, Luis R. Rodriguez wrote:
> >>>
> >>> retval = fw_state_wait_timeout(&buf->fw_st, timeout);
> >>> - if (retval < 0) {
> >>
On Tue, Jan 17, 2017 at 10:15 AM, Luis R. Rodriguez wrote:
> On Tue, Jan 17, 2017 at 03:35:05PM +, Jakub Kicinski wrote:
>> Commit 5d47ec02c37e ("firmware: Correct handling of fw_state_wait()
>> return value") made the assumption that any error returned from
>>
On Tue, Jan 17, 2017 at 11:08:46AM +0100, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn
>
> Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> ("firmware: Correct handling of fw_state_wait() return value")
> fw_load_abort(fw_priv) could be called twice. The first call would
> s
On Tue, Jan 17, 2017 at 03:35:05PM +, Jakub Kicinski wrote:
> Commit 5d47ec02c37e ("firmware: Correct handling of fw_state_wait()
> return value") made the assumption that any error returned from
> fw_state_wait_timeout() means FW load has to be aborted. This is
> incorrect, FW load only has t
> Fixes: 82a51c38f199 ("x86/platform/intel-mid: Enable RTC on Intel Merrifield")
> Cc: Luis R. Rodriguez
> Signed-off-by: Andy Shevchenko
> ---
> - add headers and #ifdef to make kbuild bot happy
> - re-test on PNP platform with acpi=off, thus, update patch ac
On Mon, Jan 16, 2017 at 02:57:06PM +, Jakub Kicinski wrote:
> Commit 5d47ec02c37e ("firmware: Correct handling of fw_state_wait()
> return value") made the assumption that any error returned from
> fw_state_wait_timeout() means FW load has to be aborted. This is
> incorrect FW load only has to
and later a fix by
Brian through 715780ae4bb76d ("firmware: actually return NULL on
failed request_firmware_nowait()).
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/drvdata.rst | 91 ++
Documentation/driver-api/firmware/index.rst| 1
get rid of our own completions.
v2: was not present
v3: initial release
v4: small cosmetic fixes
v5: bike shed changes
v6: forgot to change one piece of code during the bikeshed name change
Generated-by: Coccinelle SmPL
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intersil/p54
vzalloc() instead of vmalloc()
o bike shedding sysdata/drvdata
Signed-off-by: Luis R. Rodriguez
---
lib/Kconfig.debug | 12 +
lib/Makefile|1 +
lib/test_drvdata.c | 1033 +++
tools
p" [0].
[0] https://lkml.kernel.org/r/20170112144250.12376-1-mcg...@kernel.org
Luis R. Rodriguez (3):
firmware: add new extensible firmware API - drvdata
test: add new drvdata loader tester
p54: convert to sysdata API
Documentation/driver-api/firmware/drvdata.rst | 91 ++
Doc
: linux-l...@vger.kernel.org
Cc: Abhay Salunke
Acked-by: Jacek Anaszewski
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 7 +--
drivers/firmware/dell_rbu.c | 1 +
drivers/leds/leds-lp55xx-common.c
nux-l...@vger.kernel.org
Cc: Abhay Salunke
Acked-by: julia.law...@lip6.fr
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/fallback-mechanisms.rst| 17 +++
.../api/request_firmware-custom-fallback.cocci | 35 ++
2 files changed, 52 insertions(+)
create mode 1
*upstream* for these uses. To
avoid further issues and to help understand the reason and logic behind old
custom uses this adds a white-list upstream to help report if further faulty
uses are added upstream.
Luis R. Rodriguez (2):
firmware: add SmPL report for custom fallback mechanism
firmware
On Tue, Jan 10, 2017 at 07:57:10PM +0100, Luis R. Rodriguez wrote:
> On Fri, Dec 16, 2016 at 09:05:00AM +0100, Luis R. Rodriguez wrote:
> > On Thu, Dec 15, 2016 at 01:46:25PM +0100, Petr Mladek wrote:
> > > On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote:
> > > >
On Thu, Dec 08, 2016 at 10:47:51AM -0800, Luis R. Rodriguez wrote:
> Upon running into an old kmod v19 issue with mount (get_fs_type()) a few of us
> hunted for the cause of the issue. Although the issue ended up being a
> userspace issue, a stress test driver was written to help repr
On Fri, Dec 16, 2016 at 10:29:52AM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 14, 2016 at 10:48:37AM +0900, Milo Kim wrote:
> > Hi Jacek,
> >
> > On 12/13/2016 06:44 PM, Jacek Anaszewski wrote:
> > >
> > > Could you please verify if leds-lp55xx-comm
On Fri, Dec 16, 2016 at 08:57:26AM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 15, 2016 at 05:56:19PM +0100, Petr Mladek wrote:
> > On Thu 2016-12-08 11:49:20, Luis R. Rodriguez wrote:
> > > This adds helpers for getting access to the kmod count and limit from
> > > u
On Wed, Jan 11, 2017 at 9:49 AM, Greg KH wrote:
> On Wed, Jan 11, 2017 at 03:02:22PM +0100, Luis R. Rodriguez wrote:
>> On Wed, Jan 11, 2017 at 09:32:26AM +0100, Greg KH wrote:
>> > On Fri, Dec 16, 2016 at 03:10:37AM -0800, Luis R. Rodriguez wrote:
>> > > Even t
On Wed, Jan 11, 2017 at 09:32:26AM +0100, Greg KH wrote:
> On Fri, Dec 16, 2016 at 03:10:37AM -0800, Luis R. Rodriguez wrote:
> > Even though most distributions today disable the fallback mechanism
> > by default we've determined that we cannot remove them from the kernel.
On Wed, Dec 21, 2016 at 09:07:21PM -0800, Jessica Yu wrote:
> +++ Luis R. Rodriguez [08/12/16 11:48 -0800]:
> > diff --git a/kernel/kmod.c b/kernel/kmod.c
> > index cb6f7ca7b8a5..049d7eabda38 100644
> > --- a/kernel/kmod.c
> > +++ b/kernel/kmod.c
> > @@ -108,6 +1
On Thu, Dec 15, 2016 at 01:57:48PM +0100, Petr Mladek wrote:
> On Thu 2016-12-08 11:48:50, Luis R. Rodriguez wrote:
> > Only decrement *iff* we're possitive. Warn if we've hit
> > a situation where the counter is already 0 after we're done
> > with a modprobe
On Fri, Dec 16, 2016 at 09:39:56AM +0100, Luis R. Rodriguez wrote:
> On Wed, Dec 14, 2016 at 04:38:27PM +0100, Petr Mladek wrote:
> > On Thu 2016-12-08 11:48:14, Luis R. Rodriguez wrote:
> > > diff --git a/init/Kconfig b/init/Kconfig
> > > index 271692a352f1..da2c25746
On Fri, Dec 16, 2016 at 09:05:00AM +0100, Luis R. Rodriguez wrote:
> On Thu, Dec 15, 2016 at 01:46:25PM +0100, Petr Mladek wrote:
> > On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote:
> > > On Thu, Dec 08, 2016 at 12:29:42PM -0800, Kees Cook wrote:
> > > > On Thu,
On Mon, Jan 09, 2017 at 10:09:51PM +0100, Julia Lawall wrote:
>
>
> On Mon, 9 Jan 2017, Luis R. Rodriguez wrote:
>
> > On Mon, Dec 19, 2016 at 11:23:17AM +0100, Julia Lawall wrote:
> > >
> > >
> > > On Fri, 16 Dec 2016, Luis R. Rodriguez wrote:
>
On Mon, Jan 9, 2017 at 2:46 PM, Luis R. Rodriguez wrote:
> On Mon, Dec 19, 2016 at 11:23:17AM +0100, Julia Lawall wrote:
>> It looks suspicious that your added a new rule r0, that the python rule
>> below depends on r0 failing, and that the rule with the * (context mode)
>>
On Mon, Dec 19, 2016 at 11:23:17AM +0100, Julia Lawall wrote:
>
>
> On Fri, 16 Dec 2016, Luis R. Rodriguez wrote:
>
> > We need to ensure that when driver developers use the custom firmware
> > fallback mechanism it was not a copy and paste bug. These use cases on
>
On Fri, Jan 06, 2017 at 04:53:54PM -0500, Jessica Yu wrote:
> +++ Luis R. Rodriguez [06/01/17 21:36 +0100]:
> > On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote:
> > > "Luis R. Rodriguez" writes:
> > > > Right, out of ~350 request_m
On Tue, Jan 10, 2017 at 05:17:22AM +1030, Rusty Russell wrote:
> "Luis R. Rodriguez" writes:
> > On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote:
> >> "Luis R. Rodriguez" writes:
> >> > Right, out of ~350 request_module() calls (no
On Wed, Dec 21, 2016 at 08:48:06PM -0800, Jessica Yu wrote:
> +++ Luis R. Rodriguez [16/12/16 09:05 +0100]:
> > On Thu, Dec 15, 2016 at 01:46:25PM +0100, Petr Mladek wrote:
> > > On Thu 2016-12-08 22:08:59, Luis R. Rodriguez wrote:
> > > > On Thu, Dec 08, 2016 at 12:
On Tue, Jan 03, 2017 at 10:34:53AM +1030, Rusty Russell wrote:
> "Luis R. Rodriguez" writes:
> > Right, out of ~350 request_module() calls (not included try requests)
> > only ~46 check the return value. Hence a validation check, and come to
> > think of it, *this
On Wed, Jan 04, 2017 at 06:19:40PM +0100, linux-kernel-...@beckhoff.com wrote:
> From: Patrick Bruenn
>
> Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> ("firmware: Correct handling of fw_state_wait() return value")
>
> I see the following NULL pointer dereference:
> [0.00] Boot
On Wed, Jan 04, 2017 at 03:47:49PM +, Chris Wilson wrote:
> On Wed, Jan 04, 2017 at 04:40:49PM +0100, Luis R. Rodriguez wrote:
> > On Wed, Jan 04, 2017 at 07:12:11PM +0800, Ming Lei wrote:
> > > On Wed, Jan 4, 2017 at 5:31 PM, Chris Wilson
> > > wrote:
> >
Signed-off-by: Chris Wilson
> > Cc: Ming Lei
> > Cc: "Luis R. Rodriguez"
> > Cc: Greg Kroah-Hartman
> > ---
> > drivers/base/firmware_class.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/base/firmware_class.c
On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote:
>
> Right question is "should we solve it without user-space help"?
>
> Answer is no, too. Way too complex. Yes, it would be nice if hardware
> was designed in such a way that getting calibration data from kernel
> is easy, and if you
On Tue, Dec 20, 2016 at 8:21 PM, Rusty Russell wrote:
> "Luis R. Rodriguez" writes:
>> OK -- if userspace messes up again it may be a bit hard to prove
>> unless we have a validation debug thing in place, would such a thing
>> in debug form be reasonable ?
>
>
On Mon, Dec 19, 2016 at 6:53 PM, Rusty Russell wrote:
> Where does this NULL-deref is the module isn't correctly loaded?
No you are right, sorry -- I had confused a failure to mount over null
deref, my mistake.
>> *Iff* we want a sanity check to verify kmod's umh is not lying to us we
>> need to
On Fri, Dec 16, 2016 at 03:46:32AM -0800, Luis R. Rodriguez wrote:
> diff --git a/drivers/net/wireless/intersil/p54/p54usb.c
> b/drivers/net/wireless/intersil/p54/p54usb.c
> index 043bd1c23c19..8870d177b7d5 100644
> --- a/drivers/net/wireless/intersil/p54/p54usb.c
> +++ b/drive
On Fri, Dec 16, 2016 at 05:10:18PM +0100, Luis R. Rodriguez wrote:
> Ah, well Milo Kim replied and described that the custom fallback is used as to
> help load LED effect manually, and suggested a sysfs interface is more ideal
> [0]. I
> agree however its also may be too late, and it
On Fri, Dec 16, 2016 at 12:27:00PM +0100, Pavel Machek wrote:
> On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote:
> > On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote:
> > >
> > > Well, I was asking if the above snipped looks like valid use. Becaus
On Fri, Dec 16, 2016 at 5:27 AM, Pavel Machek wrote:
> On Fri 2016-12-16 11:56:48, Luis R. Rodriguez wrote:
>> On Fri, Dec 16, 2016 at 11:14:05AM +0100, Pavel Machek wrote:
>> >
>> > Well, I was asking if the above snipped looks like valid use. Because
>> > A
This uses the new flexible firmware API, since we don't
have to keep the firmware around the sysdata API does the
freeing for us safely.
v2: was not present
v5: bike shed changes: sysdata/drvdata
Signed-off-by: Luis R. Rodriguez
---
arch/x86/kernel/cpu/microcode/amd.c
get rid of our own completions.
v2: was not present
v3: initial release
v4: small cosmetic fixes
v5: bike shed changes
Generated-by: Coccinelle SmPL
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/intersil/p54/eeprom.c | 2 +-
drivers/net/wireless/intersil/p54/fwio.c | 5 +-
drivers
901 - 1000 of 3127 matches
Mail list logo
