On Tue, May 08, 2018 at 03:42:33PM -0700, Kees Cook wrote:
> On Tue, May 8, 2018 at 11:12 AM, Luis R. Rodriguez wrote:
> > + This used to be the default firmware loading facility, and udev
> > used
> > + to listen for uvents to load firmware for the
On Wed, May 09, 2018 at 12:12:09PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 11:12:46 -0700
> "Luis R. Rodriguez" escreveu:
>
> > It refers to a pending patch, but this was merged eons ago.
>
> Didn't know that such patch was already
From: Andres Rodriguez
This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
[mcgrof: coding style fixes, merge kdoc with enum move]
Signed-off-by: Luis R. Rodriguez
---
drivers/base
_request_nowarn() to load firmware
ath10k: re-enable the firmware fallback mechanism for testmode
Luis R. Rodriguez (7):
firmware_loader: document firmware_sysfs_fallback()
firmware_loader: enhance Kconfig documentation over FW_LOADER
firmware_loader: move kconfig FW_LOADER ent
From: Andres Rodriguez
The kernel-doc spec dictates a function name ends in ().
Signed-off-by: Andres Rodriguez
Acked-by: Randy Dunlap
Acked-by: Luis R. Rodriguez
[mcgrof: adjust since the wide API rename is not yet merged]
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader
This also sets the expecations for future fallback interfaces, even
if they are not exported.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers
From: Andres Rodriguez
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
[mcgrof: small coding style changes]
Signed-off-by: Luis R
firmware_loader/
directory later.
This also now recommends using firmwared [0] for folks left needing a uevent
handler in userspace for the sysfs firmware fallback mechanis given udev's
uevent firmware mechanism was ripped out a while ago.
[0] https://github.com/teg/firmwared
Signed-off-by: L
This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.
Signed-off-by: Luis R. Rodriguez
---
drivers/base
From: Andres Rodriguez
This reduces the unnecessary spew when trying to load optional firmware:
"Direct firmware load for ... failed with error -2"
Signed-off-by: Andres Rodriguez
Acked-by: Kalle Valo
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath10k/core.c | 2
RN when
dealing with the fallback mechanism, we will soon, so just respect
its use consistently.
And even if you *don't* want to print always on failure, you may
want to print when debugging so enable dynamic debug print when
FW_OPT_NO_WARN is used.
Signed-off-by: Luis R. Rodriguez
---
drivers/
enabled. So use that instead.
Signed-off-by: Andres Rodriguez
Acked-by: Kalle Valo
Signed-off-by: Luis R. Rodriguez
---
drivers/net/wireless/ath/ath10k/testmode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c
b/drivers/net/wireless
. Rodriguez
[mcgrof: used the old API calls as the full rename is not done yet, and
add the caller for when FW_LOADER is disabled, enhance documentation ]
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/request_firmware.rst | 5
drivers/base/firmware_loader/main.c | 27
Fix a few typos, and clarify a few sentences.
Signed-off-by: Luis R. Rodriguez
---
Documentation/driver-api/firmware/fallback-mechanisms.rst | 5 +++--
Documentation/driver-api/firmware/firmware_cache.rst | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a
It refers to a pending patch, but this was merged eons ago.
Signed-off-by: Luis R. Rodriguez
---
Documentation/dell_rbu.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 0fdb6aa2704c..077fdc29a0d0 100644
--- a/Documentation
Clarify the provenance of the firmware loader firmware_class module name
and why we cannot rename the module in the future.
Signed-off-by: Luis R. Rodriguez
---
.../driver-api/firmware/fallback-mechanisms.rst | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a
On Fri, May 04, 2018 at 10:43:49AM -0700, Luis R. Rodriguez wrote:
> Greg,
>
> I've reviewed the pending patches for the firmware_laoder and as for
> v4.18, the following 3 patches from Andres have been iterated enough
> that they're ready after I made some final m
On Fri, May 04, 2018 at 09:17:08PM +0200, Krzysztof Halasa wrote:
> "Luis R. Rodriguez" writes:
>
> > * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE
> > * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE
> >
> > To this day both of thes
o an enum
firmware: use () to terminate kernel-doc function names
firmware: rename fw_sysfs_fallback to firmware_fallback_sysfs()
Luis R. Rodriguez (3):
firmware_loader: document firmware_sysfs_fallback()
firmware_loader: enhance Kconfig documentation over FW_LOADER
firmware_loader: move
From: Andres Rodriguez
This should let us associate enum kdoc to these values.
While at it, kdocify the fw_opt.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
[mcgrof: coding style fixes, merge kdoc with enum move]
Signed-off-by: Luis R. Rodriguez
---
drivers/base
From: Andres Rodriguez
The kernel-doc spec dictates a function name ends in ().
Signed-off-by: Andres Rodriguez
Acked-by: Randy Dunlap
Acked-by: Luis R. Rodriguez
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 8
drivers/base/firmware_loader/main.c
From: Andres Rodriguez
This is done since this call is now exposed through kernel-doc,
and since this also paves the way for different future types of
fallback mechanims.
Signed-off-by: Andres Rodriguez
Acked-by: Luis R. Rodriguez
[mcgrof: small coding style changes]
Signed-off-by: Luis R
This also sets the expecations for future fallback interfaces, even
if they are not exported.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/firmware_loader/fallback.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/base/firmware_loader/fallback.c
b/drivers
firmware_loader/
directory later.
Signed-off-by: Luis R. Rodriguez
---
drivers/base/Kconfig | 160 ++-
1 file changed, 126 insertions(+), 34 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 29b0eb452b3a..bf2d464b0e2c 100644
--- a/drivers
This will make it easier to track and easier to understand
what components and features are part of the FW_LOADER. There
are some components related to firmware which have *nothing* to
do with the FW_LOADER, souch as PREVENT_FIRMWARE_BUILD.
Signed-off-by: Luis R. Rodriguez
---
drivers/base
On Sat, Apr 28, 2018 at 01:42:21AM -0700, Christoph Hellwig wrote:
> On Fri, Apr 27, 2018 at 04:14:56PM +0000, Luis R. Rodriguez wrote:
> > Do we have a list of users for x86 with a small DMA mask?
> > Or, given that I'm not aware of a tool to be able to look
> > for thi
On Thu, Apr 26, 2018 at 10:35:56PM -0700, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 09:54:06PM +0000, Luis R. Rodriguez wrote:
> > In practice if you don't have a floppy device on x86, you don't need
> > ZONE_DMA,
>
> I call BS on that,
I did not explai
Below are my notes on the ZONE_DMA discussion at LSF/MM 2018. There were some
earlier discussion prior to my arrival to the session about moving around
ZOME_DMA around, if someone has notes on that please share too :)
PS. I'm not subscribed to linux-mm
Luis
Determining you don't need to suppor
mail. Right now you
just spammed tons of people and the changes may be preferred to go
upstream atomically per driver, always assume this first.
Other than this, feel free to add to each of the patches you created:
Acked-by: Luis R. Rodriguez
From: "Luis R. Rodriguez"
If and when this gets enabled the driver could should split
up IO memory space properly and that is quite a bit of work.
Just remove the uncommented dead MTRR code then.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help
On Fri, Jun 05, 2015 at 05:17:08PM +0530, Sreekanth Reddy wrote:
> On Thu, Jun 4, 2015 at 11:11 PM, Luis R. Rodriguez wrote:
> > On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> >> Hi Luis,
> >>
> >> Sorry for delay in response. Actua
On Thu, Jun 04, 2015 at 10:20:23AM +0530, Sreekanth Reddy wrote:
> Hi Luis,
>
> Sorry for delay in response. Actually I was looking for the history of
> this section of code but I couldn't find it. Anyway this is dead code
> and we are fine with removing this dead code.
>
> James,
>
> Please con
On Fri, May 29, 2015 at 1:23 PM, Luis R. Rodriguez wrote:
> On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
>> wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> If and when this
On Wed, Apr 29, 2015 at 12:50 PM, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 1:46 PM, Luis R. Rodriguez
> wrote:
>> From: "Luis R. Rodriguez"
>>
>> If and when this gets enabled the driver could should split
>> up IO memory space properly and tha
From: "Luis R. Rodriguez"
If and when this gets enabled the driver could should split
up IO memory space properly and that is quite a bit of work.
Just remove the uncommented dead MTRR code then.
There are a few motivations for this:
a) Take advantage of PAT when available
b) Help
From: "Luis R. Rodriguez"
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pall
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 83e910a..49fe573 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -10,6 +10,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -547,15 +548,12 @@ void bus_probe_device(struct device *dev)
> {
On Tue, Oct 7, 2014 at 11:55 AM, Luis R. Rodriguez wrote:
> OK I'll just kill bus.enable_kern_async=1 to enable built-in async
> probe support *and* also have prefer_async_probe *always* be
> respected, whether modular or not.
Well and I just realized you *do* want to flush, so w
On Tue, Oct 7, 2014 at 10:55 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Oct 07, 2014 at 07:50:10PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Oct 07, 2014 at 01:34:04PM -0400, Tejun Heo wrote:
>> > But you can create a new workqueue and queue all the async probing
>>
On Tue, Oct 07, 2014 at 01:34:04PM -0400, Tejun Heo wrote:
> Hello,
>
> On Tue, Oct 07, 2014 at 01:10:46AM +0200, Luis R. Rodriguez wrote:
> > On Mon, Oct 06, 2014 at 05:01:18PM -0400, Tejun Heo wrote:
> > > For in-kernel stuff, we already have a clear
> > > synch
On Mon, Oct 06, 2014 at 05:01:18PM -0400, Tejun Heo wrote:
> Hello,
>
> On Mon, Oct 06, 2014 at 10:36:27PM +0200, Luis R. Rodriguez wrote:
> > > Do we intend to keep this param permanently? Isn't this more of a
> > > temp tool to be used during developme
On Mon, Oct 06, 2014 at 04:19:26PM -0400, Tejun Heo wrote:
> Hello, Luis.
>
> The patchset generally looks good to me. Please feel free to add
>
> Reviewed-by: Tejun Heo
Will do.
> A question below.
>
> On Fri, Oct 03, 2014 at 02:44:43PM -0700,
From: "Luis R. Rodriguez"
Some init systems may wish to express the desire to have
device drivers run their device driver's bus probe() run
asynchronously. This implements support for this and
allows userspace to request async probe as a preference
through a generic shared devic
From: "Luis R. Rodriguez"
At times we may wish to express the desire to prefer to have
a device driver probe asynchronously by default. We cannot
simply enable all device drivers to do this without vetting
that userspace is prepared for this though given that some
old userspace is e
On Fri, Oct 03, 2014 at 10:11:26PM +0200, Luis R. Rodriguez wrote:
> On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
> > + queue_work(system_unbound_wq, &priv->attach_work->work);
>
> Tejun,
>
> based on my testing so far usi
On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
> + queue_work(system_unbound_wq, &priv->attach_work->work);
Tejun,
based on my testing so far using system_highpri_wq instead of
system_unbound_wq yields close to par / better boot times
than synchronous prob
On Fri, Oct 3, 2014 at 1:23 AM, Tom Gundersen wrote:
> On Thu, Oct 2, 2014 at 10:06 PM, Luis R. Rodriguez wrote:
>> On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote:
>>> Making kmod a special case is of course possible. However, as long as
>>> there is no
On Tue, Sep 30, 2014 at 09:15:55AM +0200, Luis R. Rodriguez wrote:
> Can you provide an example code path hit here? I'll certainly like to address
> that as well.
I managed to enable built-in driver support on top of this series,
I'll send them as part of the next series but I su
On Tue, Sep 30, 2014 at 09:21:59AM +0200, Luis R. Rodriguez wrote:
> On Mon, Sep 29, 2014 at 05:26:01PM -0400, Tejun Heo wrote:
> > Hello, Luis.
> >
> > On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote:
> > > > > + /* F
time now.
On Thu, Oct 02, 2014 at 08:12:37AM +0200, Tom Gundersen wrote:
> On Tue, Sep 30, 2014 at 5:24 PM, Luis R. Rodriguez wrote:
> >> > commit e64fae5573e566ce4fd9b23c68ac8f3096603314
> >> > Author: Kay Sievers
> >> > Date: Wed Jan 18 05:06:18 2012 +0100
On Tue, Sep 30, 2014 at 11:22:14AM +0200, Tom Gundersen wrote:
> On Tue, Sep 30, 2014 at 4:27 AM, Luis R. Rodriguez wrote:
> > On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote:
> >> On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez
> >> wrote:
>
On Tue, Sep 30, 2014 at 04:27:51AM +0200, Luis R. Rodriguez wrote:
> On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote:
> > On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez
> > wrote:
> > > From: "Luis R. Rodriguez"
> > > 0) Not all driv
On Mon, Sep 29, 2014 at 05:26:01PM -0400, Tejun Heo wrote:
> Hello, Luis.
>
> On Mon, Sep 29, 2014 at 11:22:08PM +0200, Luis R. Rodriguez wrote:
> > > > + /* For now lets avoid stupid bug reports */
> > > > + if (!strcmp(bus->name, "pci&q
On Sun, Sep 28, 2014 at 12:22:47PM -0700, Dmitry Torokhov wrote:
> Hi Luis,
>
> On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
> > +static bool drv_enable_async_probe(struct device_driver *drv,
> > + struct bus_type *bus)
On Sun, Sep 28, 2014 at 07:07:24PM +0200, Tom Gundersen wrote:
> On Fri, Sep 26, 2014 at 11:57 PM, Luis R. Rodriguez
> wrote:
> > From: "Luis R. Rodriguez"
> > Systemd has a general timeout for all workers currently set to 180
> > seconds after which it will
On Mon, Sep 29, 2014 at 2:59 PM, Greg KH wrote:
>> Sure make sense, I wasn't quite sure how to make this quite clear,
>> a naming convention seems good to me but I also had added at least
>> a print about this on the log. Ideally I think a TAIN_DEBUG would
>> be best and it seems it could be usefu
On Sun, Sep 28, 2014 at 11:03:29AM -0400, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 26, 2014 at 02:57:17PM -0700, Luis R. Rodriguez wrote:
> ...
> > Systemd should consider enabling async probe on device drivers
> > it loads through systemd-udev but probably does not w
From: "Luis R. Rodriguez"
Some init systems may wish to express the desire to have
device drivers run their device driver's bus probe() run
asynchronously. This implements support for this and
allows userspace to request async probe as a preference
through a generic shared devic
On Mon, Sep 8, 2014 at 7:57 PM, Luis R. Rodriguez
wrote:
>> Why do we care about the priority of probing tasks? Does that
>> actually make any meaningful difference? If so, how?
>
> As I noted before -- I have yet to provide clear metrics but at least
> changing both in
On Tue, Sep 9, 2014 at 4:03 PM, Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 12:25:29PM +0900, Tejun Heo wrote:
>> Hello,
>>
>> On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
>> > On the systemd side of things it should enable this sysctl and for
On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen wrote:
> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
> wrote:
>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
>>> How about simply introducing a new flag to finit_module() to indicate
>>> that
On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
> On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez
> wrote:
>>>> More than two years
>>>> have gone by on growing design and assumptions on top of that original
>>>> commit. I'm not sure
On Thu, Sep 11, 2014 at 1:53 PM, Dmitry Torokhov
wrote:
> On Thu, Sep 11, 2014 at 01:42:20PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov
>> wrote:
>> >
>> >> There are elements in common, but by and
>> >&g
On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov
wrote:
>
>> There are elements in common, but by and
>> large the biggest headaches at least in large device number boots have
>> already been tackled by the enterprise crowd (they don't like their
>> S390's or 1024 core NUMA systems taking half an
Tom, thanks for reviewing this! My reply below!
On Tue, Sep 9, 2014 at 11:46 PM, Tom Gundersen wrote:
> On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
> wrote:
>> On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
>> wrote:
>>> On Tue, 2014-09-09 at 12:16 -07
On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>> wrote:
>> > If we want to sort out some sync/async mechanism for probing devices, as
>> &
On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
>> Hello, Luis.
>>
>> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
>> > > I have no idea how the selection should be. It could be
On Mon, Sep 8, 2014 at 8:03 PM, Tejun Heo wrote:
> On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote:
>> > I think we
>> > just should make exceptions sensible so that it works fine in practice
>> > for now (and I don't think that'd be t
On Mon, Sep 8, 2014 at 7:39 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote:
>> > Given that the behvaior change is from driver core and that device
>> > probing can happen post-loading anyway,
>>
>> Ah b
On Mon, Sep 8, 2014 at 6:47 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote:
>> OK then one only concern I would have with this is that the presence
>> of such a flag doesn't necessarily mean that all drivers on a syst
On Mon, Sep 8, 2014 at 6:29 PM, Tejun Heo wrote:
> On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote:
>> > Alternatively, add a module-generic param "async_probe" or whatever
>> > and use that to switch the behavior should work too. I don'
On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
>> I'm not too convinced this is such a difficult problem to figure out.
>> We already have most of logic in place and the only thing missing is
>> how to switch it. Wouldn't something li
On Fri, Sep 5, 2014 at 3:40 PM, Tejun Heo wrote:
> Hello, Luis.
>
> On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
>> Meanwhile we are allowing a major design consideration such as a 30
>> second timeout for both init + probe all of a sudden become a ha
On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
>> Which problem are we talking about here though? It does solve the slow device
>> stalling the rest if the kernel booting (non-module case) for me.
>
> The other one.
On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > From: "Luis R. Rodriguez"
> >
> > The new umh kill option has allowed kthreads to receive
> > kill signals but they are generally accepting all s
On Fri, Sep 05, 2014 at 01:24:17PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > struct driver_private {
> > struct kobject kobj;
> > struct klist klist_devices;
> > struct klist_node knode_bus;
> > struc
On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo wrote:
> On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
> ...
>> + /*
>> + * I got SIGKILL, but wait for 60 more seconds for completion
>> + * unless chosen by the OOM kil
From: "Luis R. Rodriguez"
Its reported that mptsas can at times take over 30 seconds
to recognize SCSI storage devices [0], this is done on the
driver's probe path. Use the the new asynch probe to
circumvent systemd from killing this driver.
[0] https://bugs.launchpad.net/ubunt
From: "Luis R. Rodriguez"
We now have two documented use cases for probing asynchronously:
0) since we bundle together driver init() and probe() systemd's
new 30 second timeout has put a limit on the amount of time
a driver probe routine can take, we need to enable drivers
From: "Luis R. Rodriguez"
The new umh kill option has allowed kthreads to receive
kill signals but they are generally accepting all sources
of kill signals while the original motivation was to enable
through the OOM from sending the kill. One particular user
which has been found to
From: "Luis R. Rodriguez"
cxgb4 probe can take up to over 1 minute when the firmware is
is written and installed on the device, even after this the device
driver still does some device probing and can take quite a bit.
systemd will kill this driver when probe does take over 30 second
From: "Luis R. Rodriguez"
Joseph bisected and found that Tetsuo Handa's commit 786235ee
"kthread: make kthread_create() killable" modified kthread_create()
to bail as soon as SIGKILL is received [0] [1]. This is causing some
issues with some drivers and at times boot
On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov wrote:
> And, again, I do not really know which version is better.
In Chicago right now -- feedback was it seems the that generally
splitting up probe from init might be good in the end, if we do this
we won't need a work around for drivers that wai
On Sun, Aug 17, 2014 at 02:55:05PM +0200, Oleg Nesterov wrote:
> Damn, sorry for noise ;)
>
> I was going to suggest to introduce module_put_and_exit() to simplify
> this and potentially other users, but it already exists. So this code
> can use it too without additional complications.
In the las
On Fri, Aug 15, 2014 at 04:39:02PM +0200, Oleg Nesterov wrote:
> On 08/15, Luis R. Rodriguez wrote:
> >
> > On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> > > On 08/12, Luis R. Rodriguez wrote:
> > > >
> > > > +/* To be used by
On Wed, Aug 13, 2014 at 07:51:01PM +0200, Oleg Nesterov wrote:
> On 08/12, Luis R. Rodriguez wrote:
> >
> > +/* To be used by modules which can take over 30 seconds at probe */
>
> Probably the comment should explain that this hack should only be
> used if the driver is
From: "Luis R. Rodriguez"
Tetsuo bisected and found that commit 786235ee "kthread: make
kthread_create() killable" modified kthread_create() to bail as
soon as SIGKILL is received. This is causing some issues with
some drivers and at times boot. Joseph then found that f
From: "Luis R. Rodriguez"
Its reported that mptsas can at times take over 30 seconds
to recognize SCSI storage devices [0], this is done on the
driver's probe path. Use the the new module_long_probe_init()
to annotate this driver's probe is broken and require some love,
From: "Luis R. Rodriguez"
cxgb4 probe can take up to over 1 minute when the firmware is
is written and installed on the device, even after this the device
driver still does some device probing and can take quite a bit.
This driver needs fixing but right now it simply wont' work
On Mon, Aug 11, 2014 at 11:27 AM, Takashi Iwai wrote:
> Luis R. Rodriguez wrote:
>>
>> On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote:
>> > On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote:
>> > > On Wed, Jul 30, 2014 at
On Sun, Aug 10, 2014 at 08:43:31PM +0800, Greg KH wrote:
> On Sat, Aug 09, 2014 at 06:41:19PM +0200, Luis R. Rodriguez wrote:
> > On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
> > > From: "Luis R. Rodriguez"
> > > Date: Mon, 28 Jul 2014
On Wed, Jul 30, 2014 at 03:11:07PM -0700, David Miller wrote:
> From: "Luis R. Rodriguez"
> Date: Mon, 28 Jul 2014 11:28:28 -0700
>
> > Tetsuo bisected and found that commit 786235ee "kthread: make
> > kthread_create() killable" modified kthread_c
On Wed, Jul 30, 2014 at 11:22:14AM +0900, Tetsuo Handa wrote:
> Luis R. Rodriguez wrote:
> > Tetsuo is it possible / desirable to allow tasks to not kill unless the
> > reason is OOM ? Its unclear if this was discussed before, sorry if it was,
> > have just been a bit bus
On Tue, Jul 29, 2014 at 03:25:29PM -0700, Benjamin Poirier wrote:
> On 2014/07/29 21:07, Tetsuo Handa wrote:
> > Luis R. Rodriguez wrote:
> > > On Mon, Jul 28, 2014 at 5:35 PM, Greg KH
> > > wrote:
> > > > On Mon, Jul 28, 2014 at 05:26:34PM -0700, Luis
On Tue, Jul 29, 2014 at 04:14:22PM -0700, Greg KH wrote:
> On Mon, Jul 28, 2014 at 06:13:43PM -0700, Luis R. Rodriguez wrote:
> > >> > Why not just put the initial "register the device" in a single-shot
> > >> > workqueue or thread or something like that
On Mon, Jul 28, 2014 at 5:35 PM, Greg KH wrote:
> On Mon, Jul 28, 2014 at 05:26:34PM -0700, Luis R. Rodriguez wrote:
>> On Mon, Jul 28, 2014 at 4:46 PM, Greg KH wrote:
>> > On Mon, Jul 28, 2014 at 12:48:32PM -0700, Luis R. Rodriguez wrote:
>> >> On Mon, Ju
On Mon, Jul 28, 2014 at 4:46 PM, Greg KH wrote:
> On Mon, Jul 28, 2014 at 12:48:32PM -0700, Luis R. Rodriguez wrote:
>> On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez
>> wrote:
>> > On Mon, Jul 28, 2014 at 11:55 AM, Greg KH
>> > wrote:
>> >>
On Mon, Jul 28, 2014 at 12:04 PM, Luis R. Rodriguez
wrote:
> On Mon, Jul 28, 2014 at 11:55 AM, Greg KH wrote:
>> So, what drivers are having problems in their init sequence, and why
>> aren't they using async firmware loading?
>
> Fixing drivers is one thing, fixing
On Mon, Jul 28, 2014 at 11:55 AM, Greg KH wrote:
> So, what drivers are having problems in their init sequence, and why
> aren't they using async firmware loading?
Fixing drivers is one thing, fixing drivers *now* because *now*
drivers are failing due to a regression is another thing and that's
w
On Mon, Jul 28, 2014 at 06:30:29PM +, Yuval Mintz wrote:
> > On Mon, Jul 28, 2014 at 06:52:48PM +0200, Luis R. Rodriguez wrote:
> > > On Mon, Jul 28, 2014 at 03:46:32PM +, Yuval Mintz wrote:
> > > > Sorry for not being clear, but I didn't meant 'wha
1 - 100 of 112 matches
Mail list logo
